Overview

A SchemaRegistryRestore is used for restoring schemas to a SchemaRegistry, from the data previously backed-up by a SchemaRegistryBackup in a Storage.

It is configured by creating a SchemaRegistryRestore resource in Kubernetes.

The Kannika Armory Operator creates a Job that runs the backup process, based on the configuration in the _SchemaRegistryRestore resource.

Usage

A SchemaRegistryRestore can be managed using the kubectl command line tool, and are available by the name schemaregistryrestore or schemaregistryrestores.

$ kubectl get schemaregistryrestores
NAME                         STATUS
confluent-registry-restore   🌈 Ready

Configuring a SchemaRegistryRestore

The following is an example of a SchemaRegistryRestore.

apiVersion: kannika.io/v1alpha
kind: SchemaRegistryRestore
metadata:
  name: confluent-registry-restore
spec:
  enabled: true
  registry: confluent-registry
  registryCredentialsFrom:
    credentialsRef:
      name: "http-basic-creds"
  storage: gcs-schema-storage
  storageCredentialsFrom:
    credentialsRef:
      name: "gcp-creds"

In this example:

• A SchemaRegistryRestore named confluent-registry-restore is created, as indicated by the .metadata.name field. This name will inherited by the Job running the restore process.

• The spec.enabled flag is set to true to allow restore process to start. If it is omitted or set to false, the restore process will be created in a paused state until the flag is switched to true.

• The SchemaRegistryRestore will pull data from the Storage called gcs-schema-storage as defined in the spec.storage field, and use the Credentials

• The SchemaRegistryRestore will connect to the confluent-registry SchemaRegistry to restore schemas, as indicated by the .spec.registry field, and use the Credentials referenced by confluent-registry-creds for authentication.

Note

It is likely that Restored schemas do not retain their original version after being restored. If your schemas have references to each other, a SchemaRegistryRestore will patch them with the new schema version of the referenced schema.

Import mode

Some registries such as the Confluent Cloud Schema Registry support an ‘import’ mode that will ensure that schemas will be restored with their original schema ID and version.

Caution

This will overwrite any existing schema with a conflicting schema ID or version on the target registry. Use with caution.

If the target registry’s import mode is enabled, a SchemaRegistryRestore may be configured to try and restore the original IDs and versions:

apiVersion: kannika.io/v1alpha
kind: SchemaRegistryRestore
metadata:
  name: confluent-registry-restore
spec:
  enabled: true
  importMode: true # New
  registry: confluent-registry
  registryCredentialsFrom:
    credentialsRef:
      name: "http-basic-creds"
  storage: gcs-schema-storage
  storageCredentialsFrom:
    credentialsRef:
      name: "gcp-creds"