How does schema linking work between two Schema Registries, and what role do exporters and IMPORT mode play?

## The core requirement: IDs must match Every Kafka record serialized with Schema Registry carries a **schema ID** (a magic byte plus a 4-byte ID). A consumer reads that ID and asks its registry for the schema. If you replicate *topic data* from cluster A to cluster B (via **Cluster Linking** or MirrorMaker), the records still carry A's schema IDs. If B's registry doesn't have those exact IDs mapped to the same schemas, deserialization breaks. So replicating data demands replicating schemas **with identical IDs**. ## Exporters (schema links) **Schema linking** solves this with an **exporter** — a configured, continuously-running replicator of schema versions from a source registry to a destination. You define: - the **subjects** to include (filter/patterns), - the **destination** registry connection, - the **destination context** the subjects land in, - subject renaming rules if needed. The exporter streams new and updated schema versions to the destination. Exporters are managed via the Confluent CLI (`confluent schema-registry exporter create/list/pause/resume/status`) or the REST API, and have a status (e.g. RUNNING, PAUSED) and a replication offset you can monitor. ## Contexts + IMPORT mode = ID preservation Two mechanisms make ID preservation possible: 1. **Context** — the replicated subjects go into a dedicated **context** on the destination so they don't collide with the destination's own subjects or its locally-assigned IDs. IDs are unique *within* a context. 2. **IMPORT mode** — normally the registry **auto-assigns** schema IDs and versions; you cannot dictate them. Putting a subject/context into **IMPORT mode** (a registry *mode*, alongside READWRITE/READONLY) allows registering schemas with **explicit IDs and versions**, so the destination reproduces the source's exact IDs. IMPORT mode requires the subject to be empty first (you can't import over existing versions). ## Typical topologies - **Disaster recovery / failover**: source → DR registry, so on failover consumers find identical schema IDs. - **Migration**: lift schemas to a new (e.g. Confluent Cloud) registry while preserving IDs. - **Aggregate/global registry**: many sources export into distinct contexts of one central registry. ## Import/export without continuous linking You can also do a **one-time export** of all subjects/versions (e.g. `confluent schema-registry ... export` or REST), then **import** them into a destination context in IMPORT mode — the manual equivalent of an exporter, used for migrations. ## Edge cases & gotchas - A subject/context must be **empty** to enter IMPORT mode and accept explicit IDs. - Compatibility checks may need adjusting during bulk import (often set to NONE during the import window, restored after). - Bidirectional/active-active linking needs careful context separation to avoid loops/collisions. - The exporter only handles **schemas**; the **data** is handled separately (Cluster Linking/MirrorMaker) — they must target compatible contexts/IDs. ## Why it matters Without schema linking, replicated topic data is undeserializable on the other cluster because the IDs don't resolve. Linking + contexts + IMPORT mode give you ID-stable, continuously-synced schemas for multi-cluster operations.