So what is ZooKeeper in Kafka, exactly? ZooKeeper is the external coordination service that ZooKeeper-mode Kafka clusters use to elect the controller, track which brokers are alive, and store cluster metadata — topics, partition assignments, configs, and ACLs. It is also on its way out: Apache Kafka deprecated ZooKeeper mode in 3.5 and removed it entirely in 4.0, replacing it with KRaft, a metadata quorum built into Kafka itself.

You still see ZooKeeper everywhere. Old tutorials start it before the broker, inherited clusters have zookeeper.connect in every properties file, and interview questions treat it as core Kafka knowledge. This post explains what the service actually does, what it never stored, what breaks when it fails, and why the whole layer is being retired.

How you run a ZooKeeper to KRaft migration depends entirely on where your Kafka lives. Self-managed clusters migrate in place with a rolling, dual-write procedure (KIP-866) through the Kafka 3.9 bridge release. Strimzi drives that same procedure on Kubernetes with a single annotation, Confluent Platform runs it on versions 7.6.1 through 7.9 before the KRaft-only 8.0 upgrade — and AWS MSK has no in-place path at all, which turns the migration into a cluster move.

The deadline is upstream and fixed: ZooKeeper mode was deprecated in Apache Kafka 3.5 and removed in 4.0. If you are still weighing the two modes, the KRaft vs ZooKeeper comparison settles that question. This guide assumes the decision is made and covers the part that actually carries risk: moving every cluster you have, on each platform, without losing metadata, offsets, or your rollback option.

The standard way to run Kafka MirrorMaker on Kubernetes is MirrorMaker 2 managed by the Strimzi operator, declared as a KafkaMirrorMaker2 custom resource. Two alternatives exist — a plain Deployment running the dedicated connect-mirror-maker.sh driver, or MirrorMaker 2 connectors added to a Kafka Connect cluster you already operate — and each earns its place in a specific situation.

This guide compares the three patterns, walks through a current Strimzi manifest field by field, and covers the decisions Kubernetes forces on you: scaling, placement, replication policy, cross-cluster networking, and what to watch once it runs.

To change Kafka replication factor, there is no single alter command. You change it by reassigning partitions: write a JSON plan that lists the full target replica set for each partition, then execute and verify that plan with kafka-reassign-partitions.sh. Done casually, the same procedure can saturate your network, stall producers, or leave throttles choking replication for weeks.

This is the runbook for doing it safely. It covers the preflight checks, the JSON plan, throttled execution, progress monitoring, verification, rollback, and the failure modes at each step. If you are still deciding what value to run, the replication factor guide covers choosing; this post covers changing.

How Kafka replication works in one sentence: Kafka copies each topic partition to several brokers, one copy leads, and the others follow, ready to take over. When the broker holding the leader copy fails, a follower becomes the new leader and clients carry on. That single idea is why a Kafka cluster survives dead disks and crashed machines without losing acknowledged data.

This guide is for readers meeting replication for the first time. It builds the mental model piece by piece: the vocabulary, the journey of one message, what happens during a broker failure, and a topic you can create yourself to watch it all work.

Kafka backup compliance comes down to four obligations that appear, in different words, in almost every regulation: retain topic data for a defined period, restore it on demand, prove both with tamper-evident records, and erase personal data when the law requires it. No regulation names Kafka. Auditors simply treat the events in your topics as regulated records — and broker retention, replication factor, and disk durability satisfy none of the four obligations.

Most Kafka estates that fail an audit fail on process, not technology. Retention was set by disk budget instead of regulation, no copy exists outside the cluster, and nobody can produce evidence that a restore has ever worked. This guide maps GDPR, SOX, HIPAA, and PCI DSS to the specific backup controls that close those gaps.

Kafka backup cost comes down to one dominant term — stored gigabytes multiplied by how long you keep them — plus smaller charges for requests, data transfer, and the compute that runs the backup job. Three levers cut that dominant term, and they multiply: compression shrinks every byte you store, incremental backups stop you from re-storing bytes you already have, and storage-class lifecycle rules move aged bytes to tiers that cost up to 23x less.

A naive setup — uncompressed daily fulls parked in S3 Standard — routinely costs 10 to 50 times more than an optimized pipeline holding the same data with better recovery guarantees. This guide breaks down where the money goes, walks each lever with real configuration, and prices a worked example at the end.

Kafka multi region replication is not one decision — it is three layers. A multi-region Kafka architecture combines replica placement across availability zones inside a single cluster, asynchronous replication or replicated backups across regions, and an independent backup that can rewind past the failures every replica copies faithfully. Which layers you build depends on which failure domains you must survive, and at what recovery point and recovery time.

This guide climbs the failure-domain ladder from a dead broker to a lost region to a bad deploy, shows what each layer contributes with real configuration, and closes with a decision table that maps recovery objectives to the cheapest architecture that meets them.

Kafka to Kafka replication continuously copies topics from one cluster to another using a replication tool. MirrorMaker 2 ships with Apache Kafka and is the default choice; Confluent, AWS, and others sell managed or commercial alternatives that trade money for operations.

The tool matters less than matching the mechanism to the job. Disaster recovery, cluster migration, geo distribution, aggregation, and environment seeding each pull toward different choices. And one boundary holds for all of them: replication keeps a second cluster near the present — it cannot give you yesterday back.

The Kafka Replicator vs MirrorMaker decision comes down to ownership. MirrorMaker 2 is the replication framework included with Apache Kafka: free, vendor-neutral, and built on Kafka Connect. Kafka Replicator — almost always Confluent Replicator — is Confluent's commercial connector with deeper Confluent Platform integration, including Schema Registry migration and Control Center monitoring.

The feature lists overlap heavily. The real differences sit in licensing, destination topic naming, consumer offset translation, and schema handling. Neither tool can restore yesterday's data, so neither replaces backup.