Skip to content
Kannika

    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 restore 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.

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

    Restore Status

    A SchemaRegistryRestore can have the following statuses:

    • Initializing The Restore process is being created;
    • Ready The Restore is configured but it has not been started yet;
    • Running The Restore is running and restoring to the registry;
    • Error The Restore has failed;
    • Done The Restore is complete.

    Additionally, a Restore resource exposes a JobCompleted Condition to report on the state of the underlying Job. This condition’s status can either be ‘True’ or ‘False’, and the reason field gives additional context:

    • JobInitializing the job is being started;
    • JobRunning the job is running;
    • JobCompleted the job has completed successfully;
    • JobFailed the job has failed.

    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.

    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.

    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"

    Can I choose which schemas are restored?

    Currently, a SchemaRegistryRestore will restore all data present in the Storage. In a future release, it will be possible to configure a subset of the data to restore.