Disaster Recovery in Action with Kafka and Strimzi
summary
Explains a practical Strimzi + Kafka DR setup that uses Kafka MirrorMaker 2 deployed next to the target cluster with at least three Connect workers, running the MirrorSource connector and MirrorCheckpoint connector (heartbeat disabled); shows exact CR fields, recommends identity replication policy, and warns topic deletions and many ACLs are not mirrored. Demonstrates offset-sync mechanics (mappings every 100 records, sparse power-of-two table) and gives formulas and examples (100 GB → ~33 min, 1 TB → ~6 days) to size catch‑up and plan failover.
AI-written summary · about
chapters (12)
- 0:00Disaster recovery with Kafka
- 1:48Why disaster recovery is necessary
- 3:33Cluster roles in DR setup
- 5:20MirrorMaker connectors
- 8:32MirrorMaker limitations and pitfalls
- 11:20Offset translation in MirrorMaker
- 16:42Deploying MirrorMaker with Strimzi
- 20:16Starting position for MirrorMaker
- 23:27MirrorMaker catch-up time
- 27:20Monitoring MirrorMaker
- 30:51Failover process
- 35:50Closing remarks
related talks
31mSimplifying Apache Kafka on Kubernetes With Strimzi
42mTransition to Apache Kafka on Kubernetes With Strimzi
32mStretching Strimzi: Exploring Multi-Cluster Kafka for High Availability
37mDisaster Recovery Options running Apache Kafka in Kubernetes
29mWhen GitOps goes wrong, and other challenges for Strimzi platform teams
44mTaming Apache Kafka Using GitOps
34mHow to Survive Managing Strimzi in an Enterprise
33mManaging a Kafka cluster in KRaft mode with Strimzi