Important
You are viewing documentation for an older version of Confluent Platform. For the latest, click here.
Schema Registry Single Datacenter Setup¶
Within a single datacenter or location, a multi-node, multi-broker cluster provides Kafka data replication across the nodes.
Producers write and consumers read data to/from topic partition leaders. Leaders replicate data to followers so that messages are copied to more than one broker.
You can configure parameters on producers and consumers to optimize your single cluster deployment for various goals, including message durability and high availability.
Kafka producers can set the acks configuration
parameter to control when a write is considered successful.
For example, setting producers to acks=all
requires other brokers in the
cluster acknowledge receiving the data before the leader broker responds to the
producer.
If a leader broker fails, the Kafka cluster recovers when a follower broker is elected leader and client applications can continue to write and read messages through the new leader.
Kafka Election¶
Recommended Deployment¶

Single datacenter with Kafka intra-cluster replication
The image above shows a single data center - DC A. For this example, Kafka is used for primary election, but you can also set up a single cluster with ZooKeeper.
Important Settings¶
kafkastore.bootstrap.servers
This should point to the primary Kafka cluster (DC A in this example).
schema.registry.group.id
schema.registry.group.id
is used as the consumer group.id
. For single datacenter setup, make this setting the same for all nodes in the cluster. When set, schema.registry.group.id
overrides group.id
for the Kafka group when Kafka is used for primary election. (Without this configuration, group.id
will be “schema-registry”.)
master.eligibility
In a single datacenter setup, all Schema Registry instances will be local to the Kafka cluster and should have master.eligibility
set to true.
Run Book¶
Let’s say you have Schema Registry running in a single datacenter , and the master node goes down; what do you do? First, note that the remaining Schema Registry instances can continue to serve requests.
- If one Schema Registry node goes down, another node is elected primary and the cluster auto-recovers.
- Restart the node, and it will come back as a follower (since a new primary was elected in the meantime).
Suggested Reading¶
- For an overview of schema management in Confluent Platform, including details of single primary architecture, see Schema Management and High Availability for Single Primary Setup.
- For information on multi datacenter setup for high availability, see Schema Registry Multi Datacenter Setup.
- For a broader explanation of disaster recovery design configurations and use cases, see the whitepaper on Disaster Recovery for Multi-Datacenter Apache Kafka Deployments
- Schema Registry is also available in Confluent Cloud; for details on how to lift and shift or extend existing clusters to cloud, see Migrate Schemas.