Cloudera Docs

Known Issues in Schema Registry

Learn about the known issues in Schema Registry, the impact or changes to the functionality, and the workaround.

CDPD-56890: New schemas cannot be created following an upgrade
If you delete the latest version of a schema (the one with the highest ID) from the Schema Registry database before an upgrade, you might not be able to create new schemas after you upgrade the cluster to a newer version.
  1. Access the Schema Registry database. Go to Cloudera Manager > Schema Registry > Configuration and search for "database" if you don't know the name, host, or port of the Schema Registry database.
  2. Cross reference the ID's in the schemaVersionId column of the schmema_version_state table with the ID's found in the schema_version_info table.
  3. Delete all records from the schema_version_state table that contains a schemaVersionId not present in the schema_version_info table.
CDPD-58265: Schema Registry Client incorrectly applies SSL configuration
The Cloudera distributed Schema Registry Java client might fail to apply the SSL configurations correctly with concurrent access in Jersey clients due to a Jersey issue related to JDK.
Before using HttpsURLConnection in any form concurrently, call javax.net.ssl.HttpsURLConnection.getDefaultSSLSocketFactory() once in the custom client application.
CDPD-58949: Schemas are de-duplicated on import
On import, Schema Registry de-duplicates schema versions based on their fingerprints. This means that schemas which are considered functionally equivalent in SR get de-duplicated. As a result, some schema versions are not created, and their IDs do not become valid IDs in SR.
None.
CDPD-55381: Schema Registry issues authentication cookie for the authorized user, not for the authenticated one
When the authenticated user is different from the authorized user, which can happen when Schema Registry is used behind Knox, authorization issues can occur for subsequent requests as the authentication cookie in Schema Registry stores the authorized user.
Access Schema Registry directly, without using Knox, if possible. If not, ensure that the name of the end user that tries to connect does not begin with knox.
CDPD-60160: Schema Registry Atlas integration does not work with Oracle databases
Schema Registry is unable to create entities in Atlas if Schema Registry uses an Oracle database. The following will be present in the Schema Registry log if you are affected by this issue:
ERROR com.cloudera.dim.atlas.events.AtlasEventsProcessor: An error occurred while processing Atlas events.
java.lang.IllegalArgumentException: Cannot invoke com.hortonworks.registries.schemaregistry.AtlasEventStorable.setType on bean class 'class com.hortonworks.registries.schemaregistry.AtlasEventStorable' - argument type mismatch - had objects of type "java.lang.Long" but expected signature "java.lang.Integer"

This issue causes the loss of audit data on Oracle environments.

None.
CDPD-59015: Schema Registry does not create new versions of schemas even if the schema is changed
Schema Registry uses a schema fingerprinting mechanism to differentiate between schemas. However, fingerprinting does not take into consideration the schema attributes of the field type. As a result, if you have two schemas where the only difference is that one has type attributes defined and the other does not, they will be considered identical by Schema Registry. For example, the following schemas are considered identical:
#Schema V1
{"type":"record","name":"schema_name","namespace":"ns","fields":[{"name":"local_timestamp_micros_long","type":"long"}]}

#Schema V2
{"type":"record","name":"schema_name","namespace":"ns","fields":[{"name":"local_timestamp_micros_long","type":{"type":"long","logicalType":"local-timestamp-micros"}}]}

Notice that the only difference is that in the second schema, the local_timestamp_micros_long field has a logical type specified. In cases like this, the new version of the schema is not created, the initial version is used. This is true even if the data that is being produced has a new schema version. The ID of the first schema version is used and is put in the serialized record. The new schema version is not created.

This issue is common when using change data capture (CDC) connectors like the Debezium connectors. This is because CDC connectors create schemas with the logical type decimal based on the column type in the database schema. For example:
{"type":"record","name":"schema_name","namespace":"ns","fields":[{"name":"database_column","type":{"type":"bytes","logicalType":"decimal","precision":64,"scale":0}}]}
If the database schema changes (for example, the column type), it is possible that only scale changes, which is a schema attribute.
{"type":"record","name":"schema_name","namespace":"ns","fields":[{"name":"database_column","type":{"type":"bytes","logicalType":"decimal","precision":64,"scale":1}}]}
In this case, even though scale changed to 1, the first version of the schema is used where scale is 0. As a result, the data is consumed with the wrong scale.
Avoid using logical types or other attributes. Alternatively, ensure that there are no changes in the logical types or other attributes between schema versions.
OPSAPS-68708: Schema Registry might fail to start if a load balancer address is specified in Ranger
Schema Registry does not start if the address specified in the Load Balancer Address Ranger property does not end with a trailing slash (/).
Set the value of the RANGER_REST_URL Schema Registry environment variable to an address that includes a trailing slash.
  1. In Cloudera Manager, select the Schema Registry service.
  2. Go to Configuration.
  3. Find the Schema Registry Server Environment Advanced Configuration Snippet (Safety Valve) property and add the following:
    Key: RANGER_REST_URL
Value: [***RANGER REST API URL***]
    Replace [***RANGER REST API URL***] with an address that can be used by Schema Registry to access Ranger. Ensure that the address ends with a trailing slash. For example: https://ranger-1.cloudera.com:6182/
  4. Restart the Schema Registry service.
CDPD-58990: getSortedSchemaVersions method orders by schemaVersionId instead of version number
On validation, Schema Registry orders schema versions based on ID instead of version number. In some situations, this can cause validation with the LATEST level to compare the new schema version to a non-latest version.

This situation can occur when an older version of a schema has a higher ID than the newer version of a schema, for example, when the older version is imported with an explicit ID.

None.