Belajar Debezium - Multi-Database & Multi-Cluster CDC

#Pendahuluan

Perusahaan jarang memiliki satu database — biasanya ada MySQL untuk transaksi, PostgreSQL untuk layanan lain, MongoDB untuk katalog, dan SQL Server warisan dari masa lalu. Episode 16 ini membahas bagaimana Debezium menangani banyak sumber sekaligus, baik dalam satu cluster Kafka Connect maupun lintas cluster.

Ada dua jenis kompleksitas yang akan kalian hadapi: kompleksitas operasional (mengatur banyak connector berjalan bersamaan) dan kompleksitas data (skema yang berbeda-beda harus hidup dalam satu ekosistem event). Keduanya perlu strategi yang jelas.

#Menangani Banyak Sumber Database

Satu cluster Kafka Connect bisa menjalankan banyak connector, satu per sumber database. Kuncinya adalah topic.prefix yang unik agar topic output tidak bertabrakan:

{
  "name": "mysql-inventory",
  "config": {
    "connector.class": "io.debezium.connector.mysql.MySqlConnector",
    "database.hostname": "mysql",
    "topic.prefix": "mysql-db",
    "database.include.list": "inventory"
  }
}
{
  "name": "postgres-orders",
  "config": {
    "connector.class": "io.debezium.connector.postgresql.PostgresConnector",
    "database.hostname": "postgres",
    "topic.prefix": "pg-db",
    "schema.include.list": "public"
  }
}

Dengan topic.prefix: "mysql-db" dan pg-db, event dari MySQL dan PostgreSQL tinggal di namespace berbeda dan tidak akan saling menimpa. Kedua connector berbagi resource worker yang sama, jadi perhatikan kapasitas cluster.

#Topologi Multi-Cluster

Saat skala bertambah, pisahkan connector ke cluster terpisah berdasarkan domain atau region:

cluster-transactional:  mysql-connector, sqlserver-connector
cluster-analytics:      postgres-connector, mongodb-connector

Alasan memisahkan cluster:

• Blast radius: kegagalan satu connector tidak mengganggu connector lain.
• Isolasi konfigurasi: converter dan transform berbeda per cluster.
• Skala terpisah: cluster dengan beban berat bisa di-scale sendiri.

Untuk menggabungkan event dari beberapa cluster, pakai Kafka MirrorMaker atau Cluster Linking seperti yang dibahas di episode 14.

#Konfigurasi untuk Batch Source dan Heterogeneous Schema

Sumber database berbeda menghasilkan struktur event yang berbeda pula — MySQL memakai binlog coordinate, PostgreSQL memakai LSN. Sebelum konsumen memproses, event perlu dinormalisasi. Strategi normalisasi:

{
  "transforms": "unwrap",
  "transforms.unwrap.type": "io.debezium.transforms.ExtractNewRecordState",
  "transforms.unwrap.add.fields": "op,table,source.ts_ms"
}

Transform ExtractNewRecordState melepas wrapper schema dan payload, lalu hanya menyimpan after plus bidang yang dipilih — termasuk op, nama tabel, dan timestamp. Dengan cara ini event dari MySQL, PostgreSQL, dan MongoDB punya bentuk yang konsisten untuk konsumen hilir.

#Koordinasi Antar Connector dan Consumer Groups

Saat satu konsumen ingin membaca event dari banyak database sekaligus, ia bisa masuk ke satu consumer group yang membaca banyak topic. Kafka menjamin urutan per partisi, bukan antar partisi — jadi desain konsumen harus toleran terhadap event yang datang tidak berurutan lintas sumber.

docker exec -it kafka /opt/kafka/bin/kafka-console-consumer.sh \
  --bootstrap-server localhost:9092 \
  --topic mysql-db.inventory.customers,pg-db.public.orders \
  --property print.key=true

Jika urutan lintas sumber penting — misalnya sinkronisasi relasi antar tabel — gunakan source.ts_ms untuk mengurutkan di sisi konsumen, atau pertimbangkan menjalankan transform penggabungan di Kafka Streams.

#Cross-Database Data Integration Patterns

Pola integrasi yang umum dipakai:

• Data hub: semua database mengirim event ke satu Kafka, downstream memilih yang dibutuhkan.
• Consolidation: event dari beberapa sumber digabung menjadi satu model terpadu.
• Federation: tiap sumber tetap otonom, integrasi terjadi di lapisan query atau konsumen.

Pola consolidation sering memakai satu topic untuk satu konsep bisnis. Dengan routing dari episode 6, event customers dari MySQL dan users dari PostgreSQL bisa dialihkan ke satu topic cdc-customers sebelum dinormalisasi lebih lanjut.

#Melacak Asal Setiap Event

Setelah event dari berbagai sumber digabung, kalian tetap perlu tahu asalnya. Bidang source pada event Debezium menyimpan connector, database, tabel, dan koordinat log asal. Pertahankan metadata ini saat normalisasi — jangan dibuang saat melepas wrapper dengan ExtractNewRecordState.

Gunakan properti add.fields untuk menyalin metadata penting ke level atas payload:

{
  "transforms": "unwrap",
  "transforms.unwrap.type": "io.debezium.transforms.ExtractNewRecordState",
  "transforms.unwrap.add.fields": "source.connector,source.db,source.table"
}

Dengan add.fields: "source.connector", bidang asal tersedia langsung di payload tanpa harus membongkar objek source bertingkat. Ini memudahkan downstream memfilter atau mengelompokkan event berdasarkan sumbernya.

#Penutup

Episode 16 memperluas cakupan pipeline: banyak connector dalam satu cluster dengan topic.prefix unik, pemisahan cluster untuk isolasi dan skala, normalisasi event yang heterogen, koordinasi consumer group, dan pola integrasi lintas database.

Inti yang harus dibawa pulang:

• Satu cluster bisa menjalankan banyak connector selama topic.prefix masing-masing unik.
• Multi-cluster memberi isolasi kegagalan dan skala yang terpisah.
• ExtractNewRecordState menormalkan event dari sumber yang berbeda ke satu bentuk.
• Urutan hanya dijamin per partisi; urutkan lintas sumber di sisi konsumen jika perlu.
• Pilih pola data hub, consolidation, atau federation sesuai kebutuhan bisnis.

Di episode 17 selanjutnya kita akan membahas custom SMT dan connector extensions — menulis Single Message Transforms sendiri, memperluas Debezium dengan plugin transformasi baru, dan use case masking, enrichment, serta normalisasi payload.