Belajar Debezium - Distributed Deployment & High Availability

#Pendahuluan

Selama ini kita menjalankan satu worker Kafka Connect — titik tunggal kegagalan. Jika worker itu mati, semua connector ikut berhenti. Episode 12 ini membahas menjalankan Kafka Connect cluster dengan beberapa worker, sehingga kegagalan satu worker tidak menghentikan pipeline dan beban bisa dibagi antar worker.

Distributed mode adalah cara kerja default Kafka Connect saat kalian tidak memakai mode standalone. Semua keputusan — penjadwalan task, pembagian beban, dan pemulihan — diambil oleh cluster secara otomatis menggunakan group coordination di Kafka.

#Menjalankan Kafka Connect Cluster Secara Terdistribusi

Kunci cluster adalah beberapa worker yang berbagi group.id, bootstrap.servers, dan tiga topic internal yang sama. Tambahkan worker kedua di compose:

  connect-2:
    image: quay.io/debezium/connect:3.0
    ports:
      - "8084:8083"
    environment:
      BOOTSTRAP_SERVERS: kafka:9092
      GROUP_ID: 1
      CONFIG_STORAGE_TOPIC: connect-configs
      OFFSET_STORAGE_TOPIC: connect-offsets
      STATUS_STORAGE_TOPIC: connect-status

Perhatikan GROUP_ID: 1 yang sama dengan worker pertama. Dengan group id yang sama, kedua worker tergabung dalam satu cluster dan berbagi tugas.

Verifikasi dari REST API — kedua worker melayani endpoint yang sama karena koordinasi di dalam cluster:

curl -s http://localhost:8083/connectors

#High Availability dan Fault Tolerance

Saat satu worker mati, task yang sedang berjalan di worker itu otomatis dipindahkan ke worker lain. Pemulihan ini dilakukan lewat mekanisme rebalancing group Kafka Connect:

worker-1 (task 0, 1) ── mati ──► rebalance
worker-2 (task 2)    ──────────► worker-2 (task 0, 1, 2)

Karena offset disimpan di topic bersama, task yang dipindahkan melanjutkan dari posisi terakhir — tidak ada data yang dibaca ulang dari awal. Inilah keuntungan menyimpan offset di Kafka, bukan di disk lokal worker.

Untuk menambah redundansi di sisi sumber, jalankan connector di cluster yang berbeda dengan snapshot terpisah, atau gunakan heartbeat agar posisi baca tetap segar selama failover.

#Balanced Workloads dan Worker Scaling

Debezium membagi work sesuai jumlah task. Konfigurasi tasks.max menentukan berapa banyak task yang bisa dibuat, dan cluster membaginya ke seluruh worker:

{
  "tasks.max": "4"
}

Dengan tasks.max: "4", connector membuat empat task yang tersebar merata di kedua worker. Saat beban naik, tambahkan worker baru — Kafka Connect otomatis menyeimbangkan kembali task tanpa menghentikan connector:

docker compose up -d connect-3

Proses rebalance memindahkan sebagian task ke worker baru. Untuk meminimalkan jeda, beberapa versi Kafka Connect mendukung cooperative rebalancing yang memindahkan task satu per satu.

#Redundansi Sumber Data dan Connector Failover

Cluster Kafka Connect menangani kegagalan worker, tetapi bukan kegagalan sumber. Jika database utama mati, connector tetap gagal meskipun cluster sehat. Redundansi sumber dilakukan dengan pola:

• Read replica: arahkan connector ke replica yang siap mengambil alih saat primer mati.
• Active-passive: jalankan connector di dua region, hanya satu yang aktif streaming.
• Failover terencana: alihkan koneksi database connector melalui DNS atau load balancer.

Untuk failover cepat, siapkan juga properti retry koneksi di connector:

{
  "connect.timeout.ms": "30000",
  "connect.backoff.max.delay.ms": "60000",
  "connect.backoff.initial.delay.ms": "1000"
}

Dengan connect.backoff.max.delay.ms: "60000", connector mencoba kembali dengan jeda hingga satu menit saat database tidak tersedia, memberi waktu bagi sumber untuk pulih.

#Konfigurasi Worker yang Sama Persis

Agar cluster bekerja dengan benar, seluruh worker harus memakai konfigurasi inti yang identik: bootstrap.servers, group.id, dan ketiga nama topic internal. Ketidakcocokan salah satu nilai akan membuat worker terpecah menjadi cluster yang berbeda — gejala umumnya adalah connector yang terdaftar lewat satu worker tidak terlihat di worker lain.

GROUP_ID: 1
CONFIG_STORAGE_TOPIC: connect-configs
OFFSET_STORAGE_TOPIC: connect-offsets
STATUS_STORAGE_TOPIC: connect-status

Jika OFFSET_STORAGE_TOPIC: connect-offsets tidak cocok antar worker, task bisa membaca offset dari topic yang berbeda dan menghasilkan posisi baca yang tidak konsisten. Seragamkan konfigurasi melalui templat compose atau Helm chart agar tidak terjadi kesalahan manual.

#Penutup

Episode 12 mengangkat pipeline kalian dari satu titik menjadi cluster yang tangguh: beberapa worker berbagi tugas, kegagalan worker dipulihkan otomatis, task tersebar merata dan bisa di-scale, serta redundansi sumber menyiapkan failover yang sesungguhnya.

Inti yang harus dibawa pulang:

• Distributed mode aktif saat beberapa worker berbagi group.id dan topic internal yang sama.
• Offset di Kafka memungkinkan failover task tanpa membaca ulang data dari awal.
• tasks.max membagi beban ke seluruh worker; menambah worker menyeimbangkan kembali tugas.
• Cluster Connect tidak melindungi dari kegagalan database sumber.
• Redundansi sumber memakai read replica atau pola active-passive.

Di episode 13 selanjutnya kita akan membahas auditability dan data observability — menelusuri perubahan database dan rekonstruksi event stream, audit trail untuk CRUD dan schema change, observability dengan metrics, logs, dan tracing.