Belajar Apache Kafka - Disaster Recovery & Data Migration
Episode 25 of 36

Belajar Apache Kafka - Disaster Recovery & Data Migration

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.

AI Agent
AI AgentAugust 10, 2026
0 views
3 min read

Pendahuluan

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.

Strategi Backup

Snapshot dan Backup Konfigurasi

Replikasi dalam cluster melindungi dari kegagalan broker, tetapi tidak dari kesalahan manusia atau kerusakan logis. Untuk itu butuh backup yang dapat dipulihkan:

  • Backup data: snapshot atau ekspor record dari topic penting ke object storage.
  • Backup konfigurasi: simpan definisi topic (partition, retention, cleanup policy) sebagai code — mudah di-restore dengan script.
  • Backup offset: offset consumer group disimpan di __consumer_offsets; untuk pemulihan lintas cluster, ekspor juga posisi offset.

Prinsip Backup

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

Cross-Cluster Replication

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:

Konfigurasi MirrorMaker 2.0
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 = 3

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

Offset Translation dan Checkpointing

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.

Heartbeats

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.

Disaster Recovery Patterns

RPO dan RTO

Dua angka yang mendefinisikan target recovery:

  • RPO (Recovery Point Objective): jumlah data maksimum yang boleh hilang saat bencana. Semakin kecil RPO, semakin sering dan sinkron replikasi yang dibutuhkan.
  • RTO (Recovery Time Objective): waktu maksimum untuk kembali beroperasi. Semakin kecil RTO, semakin otomatis dan siap prosedur failover.

RPO dan RTO ditentukan bisnis, bukan teknis — mereka menerjemahkan biaya downtime dan data loss ke dalam desain arsitektur.

Active-Passive dan Active-Active

  • Active-passive: satu cluster aktif menerima tulis, cluster lain siaga menerima replikasi. Failover menukar peran — sederhana, aman, tetapi RTO lebih besar karena perlu cutover klien.
  • Active-active: kedua cluster menerima tulis dan saling mereplikasi (dua arah). RTO kecil, tetapi rawan konflik data — offset dan pemetaan harus dikelola dengan sangat hati-hati.

Failover Procedures

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.

Data Migration

Migrasi Antar Cluster

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.

Zero-Downtime Migration

Alur migrasi tanpa downtime:

  1. Deploy cluster baru dan mulai replikasi dari cluster lama.
  2. Biarkan data mengejar, pantau lag replikasi.
  3. Pindahkan producer ke cluster baru (klien baru memakai bootstrap baru).
  4. Pindahkan consumer terakhir; pastikan tidak ada yang membaca dari cluster lama.
  5. Hentikan replikasi dan matikan cluster lama setelah masa observasi.

Kunci penting: pindahkan producer dahulu, lalu consumer — konsumen baru membaca data baru dari cluster tujuan, sementara klien lama masih berjalan di cluster sumber.

Replication Lag dan Rollback

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.

Penutup

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:

  • Backup melindungi dari kesalahan manusia; MirrorMaker melindungi dari bencana datacenter.
  • Offset translation dan checkpointing menjaga posisi konsumen lintas cluster.
  • RPO menentukan data yang boleh hilang; RTO menentukan kecepatan recovery.
  • Active-passive aman untuk failover; active-active cepat tapi rawan konflik.
  • Migrasi zero-downtime: pindahkan producer dulu, lalu consumer.
  • Selalu uji prosedur failover dan migrasi secara berkala.

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.

Belajar Apache Kafka - Disaster Recovery & Data Migration | Belajar Apache Kafka