Episode ini membahas disaster recovery dan migrasi data: strategi backup, MirrorMaker 2.0 untuk replikasi lintas cluster, offset translation dan checkpointing, pola active-active dan active-passive, pertimbangan RPO/RTO, serta migrasi cluster zero-downtime.

Tidak ada cluster yang kebal bencana: kerusakan datacenter, kesalahan konfigurasi, atau penghapusan accidental bisa melumpuhkan produksi. Disaster recovery adalah rencana yang menjawab pertanyaan: seberapa cepat kalian bisa kembali beroperasi, dan seberapa banyak data yang boleh hilang?
Episode 25 ini akan membahas strategi backup, MirrorMaker 2.0 untuk replikasi lintas cluster, konsep RPO dan RTO, pola active-active dan active-passive, serta migrasi data antar cluster tanpa downtime.
Replikasi dalam cluster melindungi dari kegagalan broker, tetapi tidak dari kesalahan manusia atau kerusakan logis. Untuk itu butuh backup yang dapat dipulihkan:
__consumer_offsets; untuk pemulihan lintas cluster, ekspor juga posisi offset.Backup harus diuji, bukan sekadar dibuat. Latihan restore berkala memastikan kalian tahu cara memulihkan dan berapa lama. Kombinasikan beberapa lapis: replikasi untuk broker failure, backup untuk kesalahan manusia, dan MirrorMaker untuk bencana datacenter.
MirrorMaker 2.0 adalah tool resmi untuk mereplikasi data antar cluster. Ia memakai Kafka Connect (episode 12): satu connector per topic source, dengan worker yang membaca dan menulis lintas cluster:
clusters = primary, backup
primary.bootstrap.servers = primary.example.com:9092
backup.bootstrap.servers = backup.example.com:9092
primary->backup.enabled = true
primary->backup.topics = orders, user-events
replication.factor = 3primary->backup.enabled = true mengaktifkan replikasi satu arah dari primary ke backup. Topic direplikasi dengan nama yang sama; offset diubah selama proses agar posisi konsumen tetap bermakna di sisi tujuan.
Bagian paling rumit replikasi: offset di cluster sumber tidak sama dengan offset di cluster tujuan. MirrorMaker 2.0 menangani ini dengan offset translation — memetakan offset sumber ke offset tujuan — dan checkpointing, mencatat pemetaan tersebut ke topic internal secara berkala. Consumer di sisi backup bisa dilanjutkan dari posisi yang kira-kira sama dengan di sisi primary.
MirrorMaker mengirim heartbeat topic (heartbeats) untuk memantau kesehatan koneksi replikasi. Dengan heartbeat, kalian tahu seberapa jauh replikasi tertinggal dan apakah koneksi antar cluster berfungsi — metrik penting untuk menilai kesiapan failover.
Dua angka yang mendefinisikan target recovery:
RPO dan RTO ditentukan bisnis, bukan teknis — mereka menerjemahkan biaya downtime dan data loss ke dalam desain arsitektur.
Prosedur failover yang baik: verifikasi kesehatan cluster backup, hentikan tulis di primary, konfirmasi sinkronisasi terakhir, arahkan klien ke backup, lalu nyalakan replicator arah sebaliknya. Semua langkah harus diuji dalam latihan berkala — prosedur yang tidak pernah diuji akan gagal di saat krisis.
MirrorMaker juga menjadi alat migrasi: buat cluster baru, replikasi dari yang lama, lalu pindahkan klien satu per satu. Kunci sukses adalah mempertahankan urutan yang benar untuk topic dengan konsumen yang harus melanjutkan dari posisi tertentu.
Alur migrasi tanpa downtime:
Kunci penting: pindahkan producer dahulu, lalu consumer — konsumen baru membaca data baru dari cluster tujuan, sementara klien lama masih berjalan di cluster sumber.
Selama migrasi, pantau replikasi lag terus-menerus. Siapkan rollback plan: jika masalah ditemukan, arahkan klien kembali ke cluster lama — selama replikasi dua arah atau checkpoint masih memungkinkan. Setelah cluster lama dimatikan, rollback jauh lebih sulit; pertahankan masa observasi yang cukup sebelum dekomisioning.
Info
MirrorMaker 2.0 bukan backup: ia membutuhkan cluster tujuan yang berjalan. Untuk data yang benar-benar harus dipertahankan, kombinasikan replikasi lintas cluster dengan backup ke object storage yang tidak bergantung pada Kafka.
Di episode 25 ini kalian sudah memahami strategi backup, MirrorMaker 2.0 dengan offset translation dan checkpointing, konsep RPO dan RTO, pola active-active dan active-passive, serta prosedur migrasi zero-downtime antar cluster.
Inti yang harus dibawa pulang:
Di episode 26 selanjutnya kita akan membahas Kafka dalam arsitektur microservices — event-driven architecture, pola saga, CQRS, dan outbox. Kalian akan belajar choreography, domain events, serta transactional outbox dengan Debezium.