Belajar Debezium - Operational Readiness & Runbooks

#Pendahuluan

Pipeline CDC akan gagal — pertanyaannya bukan "apakah", melainkan "kapan dan seberapa cepat pulih". Episode 19 ini membahas operational readiness: dokumen runbook yang berisi langkah persis saat connector gagal, prosedur memulai ulang snapshot dan data replay, strategi backup, serta drill untuk menguji rencana pemulihan.

Runbook yang baik bukan teori: dia berisi perintah konkret yang bisa dijalankan saat panik. Dengan latihan rutin, tim tidak perlu bereksperimen di tengah insiden produksi.

#Menyusun Runbook untuk Connector Failure

Langkah pertama setiap insiden adalah diagnosis. Standarkan langkah ini di runbook:

curl -s http://localhost:8083/connectors/inventory-connector/status | jq
docker logs connect --tail 100

Jika connector dalam state FAILED, restart dengan aman:

curl -s -X POST http://localhost:8083/connectors/inventory-connector/restart
curl -s -X POST http://localhost:8083/connectors/inventory-connector/tasks/0/restart

Jangan langsung menghapus connector saat gagal — hapus dulu akar masalahnya, karena menghapus dan mendaftarkan ulang bisa memicu snapshot baru yang jauh lebih mahal.

#Snapshot Restart dan Data Replay

Saat offset rusak atau data perlu dimuat ulang, kalian butuh prosedur snapshot ulang yang terkendali. Tiga skenario:

• Replay total: hapus connector dan topic, lalu daftarkan ulang dengan snapshot.mode: initial.
• Snapshot ulang sebagian: pakai incremental snapshot untuk tabel tertentu tanpa menghentikan streaming.
• Replay dari titik tertentu: atur offset awal sebelum memulai connector.

Untuk menjalankan snapshot ulang tanpa menghentikan streaming yang lain, gunakan signal table seperti episode 4:

Memicu snapshot ulang satu tabel

INSERT INTO inventory.debezium_signal
  (id, type, data) VALUES
  ('replay-1', 'execute-snapshot', '{"data-collections": ["inventory.orders"]}');

Sebelum memicu execute-snapshot, pastikan konsumen sudah siap menerima event op: r yang akan masuk kembali.

#Incident Response untuk Connector Lag dan Schema Issue

Dua insiden paling umum adalah lag tinggi dan schema mismatch.

Lag tinggi — langkah respons:

1. Identifikasi sumber lag: database lambat, worker kehabisan resource, atau jaringan bermasalah.
2. Cek metrik JMX Lag dan log worker.
3. Percepat sementara dengan menaikkan max.batch.size, lalu normalisasi setelah pulih.

Schema mismatch — langkah respons:

1. Identifikasi event yang ditolak dari DLQ atau log error.
2. Bandingkan skema terbaru di schema registry dengan skema konsumen.
3. Update konsumen atau beri default pada kolom baru di sisi sumber.

Simpan kedua prosedur ini sebagai bagian runbook sehingga siapapun di tim bisa mengeksekusinya.

#Backup Config, Offsets, dan Source Metadata

Kemampuan pemulihan bergantung pada ketersediaan backup:

• Config: definisi connector sudah di git via GitOps (episode 11).
• Offsets: topic connect-offsets perlu di-backup agar posisi baca bisa dipulihkan.
• Source metadata: posisi binlog atau LSN terakhir sebagai patokan tambahan.

Amankan topic offset dengan mirrornya ke cluster cadangan:

docker exec -it kafka /opt/kafka/bin/kafka-mirror-maker.sh \
  --consumer.config /kafka/consumer.properties \
  --producer.config /kafka/producer.properties \
  --whitelist connect-offsets

Perintah kafka-mirror-maker.sh --whitelist connect-offsets di atas menyalin topic offset secara berkala ke cluster cadangan, sehingga pemulihan tidak bergantung pada satu mesin.

#Drill Recovery dan Failover Testing

Dokumen tanpa latihan hanyalah harapan. Jadwalkan drill berkala:

• Drill snapshot restart: matikan connector, hapus offset sebagian, pulihkan dengan runbook.
• Drill failover worker: matikan satu worker, pastikan task pindah otomatis.
• Drill replay: replay satu tabel dengan incremental snapshot dan verifikasi konsumen.

Ukur metrik penting saat drill — recovery time objective (RTO) dan data loss tolerance — lalu perbaiki runbook berdasarkan temuan. Drill yang sukses membuat tim percaya diri saat insiden nyata datang.

#Checklist Runbook Minimal

Sebuah runbook yang baik mencakup elemen berikut:

• Gejala yang memicu insiden, misalnya state connector FAILED.
• Perintah diagnosis yang pasti, dengan contoh output yang diharapkan.
• Langkah perbaikan berurutan, dari yang paling aman hingga yang paling drastis.
• Prosedur eskalasi dan siapa yang dihubungi saat langkah tidak berhasil.
• Bagian post-mortem untuk mencatat temuan dan perbaikan.

Simpan runbook di repository bersama konfigurasi connector, agar versinya selalu sinkron dengan kondisi pipeline terkini.

#Penutup

Episode 19 membawa kalian ke mode siap produksi: runbook diagnosis dan restart, prosedur snapshot restart dan replay, respons insiden untuk lag dan schema, backup config serta offset, dan drill pemulihan yang menguji rencana secara nyata.

Inti yang harus dibawa pulang:

• Dokumentasikan perintah diagnosis dan restart di runbook yang mudah diakses.
• Jangan menghapus connector saat gagal tanpa menghapus akar masalahnya.
• Snapshot ulang bisa dilakukan per tabel dengan signal table.
• Backup config, offset, dan metadata sumber adalah prasyarat pemulihan.
• Jadwalkan drill dan ukur RTO untuk memvalidasi runbook.

Di episode 20 selanjutnya kita akan membahas real-world use cases dan patterns — sinkronisasi microservices, analytics pipeline, cache berbasis CDC, event sourcing dan audit logs, read scaling, serta arsitektur end-to-end.