.. _schemaregistry_single-dc: |sr| Single Datacenter Setup ============================ Within a single datacenter or location, a multi-node, multi-broker cluster provides |ak| 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. |ak| :ref:`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 |ak| cluster recovers when a follower broker is elected leader and client applications can continue to write and read messages through the new leader. |ak| Election -------------- Recommended Deployment ^^^^^^^^^^^^^^^^^^^^^^ .. figure:: ../images/single-dc-setup.png :align: center Single datacenter with |ak| intra-cluster replication The image above shows a single data center - DC A. For this example, |ak| is used for primary election, but you can also set up a single cluster with |zk|. Important Settings ^^^^^^^^^^^^^^^^^^ ``kafkastore.bootstrap.servers`` This should point to the primary |ak| 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 |ak| group when |ak| is used for primary election. (Without this configuration, ``group.id`` will be "schema-registry".) ``master.eligibility`` In a single datacenter setup, all |sr| instances will be local to the |ak| cluster and should have ``master.eligibility`` set to true. Run Book ^^^^^^^^ Let's say you have |sr| running in a single datacenter , and the master node goes down; what do you do? First, note that the remaining |sr| instances can continue to serve requests. - If one |sr| 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 |cp|, including details of single primary architecture, see :ref:`schemaregistry_intro` and :ref:`sr-high-availability-single-primary`. - For information on multi datacenter setup for high availability, see :ref:`schemaregistry_mirroring`. - For a broader explanation of disaster recovery design configurations and use cases, see the whitepaper on `Disaster Recovery for Multi-Datacenter Apache Kafka Deployments `_ - |sr| is also available in |ccloud|; for details on how to lift and shift or extend existing clusters to cloud, see :ref:`schemaregistry_migrate`.