Troubleshooting in Yandex MetaData Hub
This section describes issues you may encounter in the service and how to troubleshoot them.
Troubleshooting in Hive Metastore
Error when creating a database in Hive Metastore
The error occurs if you use the following syntax to create a database:
CREATE DATABASE IF NOT EXISTS <DB_name>;
Solution
Metastore does not allow creating a database or table in Hive: they are stored in a Yandex Object Storage bucket linked to a Yandex Data Processing cluster. To create a database, use the following syntax:
CREATE DATABASE IF NOT EXISTS <DB_name> LOCATION <DB_location>;
In the LOCATION
parameter, specify the path to the bucket and the database in it in the following format: s3a://<bucket_name>/<folder_name>/<DB_name>
. Specifying a folder is optional; however, objects will load into a folder faster than into the bucket root.
No permission error when connecting a service account to the cluster
Error message:
ERROR: rpc error: code = PermissionDenied desc = you do not have permission to access the requested service account or service account does not exist
This error occurs if you link a service account to a cluster while creating or modifying it.
Solution
Assign the iam.serviceAccounts.user role or higher to your Yandex Cloud account.
Troubleshooting in Yandex Schema Registry
Error when adding or deleting optional parameters
If a Confluent
compatibility check policy is configured at the namespace level, the following errors may occur when adding or deleting optional parameters in the schema:
PROPERTY_ADDED_TO_OPEN_CONTENT_MODEL
.PROPERTY_REMOVED_FROM_CLOSED_CONTENT_MODEL
.
Solution
The Confluent
compatibility check policy is based on the Confluent Schema Registry standards and implements mathematically accurate compatibility checks. This policy does not allow adding or removing optional parameters in object
fields, causing the errors mentioned above.
To add or delete optional parameters, select the optional-friendly
JSON compatibility check policy in the namespace. It is based on using various content models for the producer and the consumer, where only the producer schema is registered. The compatibility check involves converting the consumer schema from an open content model to a closed one and comparing it with the registered producer schemas. This enables you to add or remove optional parameters while maintaining full transitive compatibility.