22 posts tagged with "Replication"

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 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.

Kafka MirrorMaker 2 offset sync is the mechanism that maps a consumer group's committed position on the source cluster to the equivalent position on the target cluster. The same record almost never sits at the same offset in both logs, so MirrorMaker 2 records source-to-target offset pairs in an internal offset-syncs topic and emits per-group checkpoints that failover consumers use to resume without reprocessing or skipping data.

Topic data that fails over without consumer positions is an incomplete disaster recovery story. Applications either replay hours of duplicates or silently skip records. This guide explains the machinery behind offset translation: the three internal topics, the checkpoint flow, automated group offset sync, the tuning knobs with their real defaults, and the places where the mechanism breaks down.

In-sync replicas (ISR) are the subset of a Kafka partition's replicas that are currently caught up with the leader — the leader itself, plus every follower that has fetched to the leader's latest offset within replica.lag.time.max.ms (30 seconds by default). The ISR is the mechanism behind every guarantee Kafka makes: only ISR members confirm acks=all writes, and only ISR members can become leader without losing data.

Replication factor is a static promise; the ISR is the live measurement of how much of that promise currently holds. This guide explains how replicas join and leave the ISR, what the high watermark commits, how min.insync.replicas and acks form a durability contract, and what happens during leader election when the ISR has shrunk.

Kafka under-replicated partitions (URPs) are partitions whose in-sync replica (ISR) count has dropped below their replication factor. One or more follower replicas has either died or fallen behind the leader for longer than replica.lag.time.max.ms — 30 seconds by default. Every broker reports the count through the UnderReplicatedPartitions JMX gauge, and any value above zero means the cluster is running with less redundancy than you configured.

URP is the most-watched health metric in Kafka operations for a simple reason: it measures how much failure margin remains before an outage becomes data loss. This guide covers what the metric means, the commands that find the failing broker, a fix for each root cause, and the alert thresholds that separate routine maintenance from a real incident.

Kafka active-active replication runs two or more clusters that all serve producers and consumers, with bidirectional replication keeping them converged. Every region writes locally, reads locally, and receives the other regions' data within seconds.

Kafka has no native multi-master mode, so active-active is an architecture you assemble — from a cross-cluster replication tool plus application-level discipline. Three problems define the assembly: replication loops, consumer offset divergence, and the complete absence of conflict resolution.