# ZooKeeper Topic Guide In older versions of Apache Kafka®, Kafka ZooKeeper was used to store persistent cluster metadata. In Confluent Platform 8.0 and later, ZooKeeper has been removed and you now run Kafka in KRaft mode, meaning brokers that are in KRaft mode store their metadata in a KRaft quorum. This is the new and improved mode of handling metadata in Kafka. For more information on KRaft, see [KRaft Overview for Confluent Platform](kraft.md#kraft-overview). To find topics on ZooKeeper, search in the [Confluent Platform 7.9 documentation](https://docs.confluent.io/platform/7.9/overview.html) for the term ‘ZooKeeper’, or see the following links: - Hardware requirements: For ZooKeeper hardware requirements, configuration, monitoring, and more in Confluent Platform 7.9.x and earlier, see [hardware](https://docs.confluent.io/platform/7.9/kafka-metadata/zk-production.html). - Security with ZooKeeper: For a tutorial on securing a ZooKeeper- based cluster Confluent Platform version 7.9.x and earlier, see [ZooKeeper Security](https://docs.confluent.io/platform/7.9/security/component/zk-security.html), and [Enable Security for a ZooKeeper-Based Cluster in Confluent Platform](https://docs.confluent.io/platform/7.9/security/security_tutorial.html). - Best practices: For best practices running ZooKeeper in production for Confluent Platform 7.9.x and earlier, see [Kafka in ZooKeeper mode](https://docs.confluent.io/platform/7.9/kafka/deployment.html#ak-in-zk-mode). - Upgrade Kafka with ZooKeeper: For ZooKeeper upgrade instructions in Confluent Platform version 7.9.x and earlier, see [upgrade](https://docs.confluent.io/platform/7.9/installation/upgrade.html#steps-for-upgrading-to-version-x-zk-mode). - Running ZooKeeper with Docker: For instructions on configuring Kafka in ZooKeeper mode with Docker, see [ZooKeeper Mode](https://docs.confluent.io/platform/7.9/installation/docker/config-reference.html#required-ak-configurations-for-zk-mode). ## Broker recovery after network disruptions in ZooKeeper-based deployments In ZooKeeper-based deployments running Confluent Platform 7.9 and earlier, brokers register themselves with ZooKeeper on startup. After a transient ZooKeeper authentication failure — such as one caused by a network disruption — a broker’s ZooKeeper session may be invalidated. Unlike KRaft mode, ZooKeeper mode does not include automatic retry logic for broker re-registration. As a result, the broker process may continue running, but the broker will not automatically rejoin the cluster. #### IMPORTANT ZooKeeper-based deployments have a known limitation in broker re-registration behavior. Confluent will not pursue a software fix for this behavior in ZooKeeper mode. KRaft mode resolves this limitation and includes automatic broker re-registration retry logic. If brokers fail to recover after a transient ZooKeeper authentication failure, perform the following recovery steps: 1. **Identify affected brokers.** Review your monitoring or cluster health dashboards to identify brokers that appear offline or are not receiving traffic even though the network disruption has resolved. 2. **Restart the affected brokers.** Restart broker processes one at a time to minimize cluster impact: ```none sudo systemctl restart confluent-server ``` If you installed the community package, use `confluent-kafka` instead of `confluent-server`. Wait for each broker to fully rejoin the cluster before restarting the next one. 3. **Verify cluster recovery.** Confirm that all brokers have re-registered with ZooKeeper and are accepting traffic. Check broker status using: ```none kafka-broker-api-versions --bootstrap-server : | grep 'id: ' ``` To resolve this limitation, migrate your cluster from ZooKeeper to KRaft. For instructions, see [Migrate from ZooKeeper to KRaft on Confluent Platform](../installation/migrate-zk-kraft.md#migrate-zk-kraft). ## Related content - [Migrate from ZooKeeper to KRaft on Confluent Platform](../installation/migrate-zk-kraft.md#migrate-zk-kraft) - [KRaft Configuration for Confluent Platform](config-kraft.md#configure-kraft)