DEBI PRAHARADIKA
← Back to Blog Index
Data Engineering2026-09-0710 min read

Arsitektur Zero-Downtime CDC dari MySQL InnoDB ke ClickHouse untuk Real-Time OLAP

Migrasi beban analitik dari MySQL ke ClickHouse tanpa menghentikan sistem produksi. Memahami secara singkat arsitektur event-driven menggunakan Change Data Capture (CDC).

"Data gravity is real. But the true engineering challenge is not storing the data, it's mutating its form from an operational state to an analytical state in real-time, without skipping a single heartbeat."

Sebuah aplikasi SaaS (Software-as-a-Service) atau platform e-commerce biasanya database transaksional menggunakan MySQL InnoDB atau PostgreSQL. Saat pertumbuhan pengguna dan data yang besar maka operasi dasar seperti INSERT dan UPDATE yang disebut dengan OLTP / Online Transaction Processing akan berjalan lancar. Namun, ketika tim analis data membuka Dashboard Analytics yang mengeksekusi kueri agregrasi sangat besar (OLAP / Online Analytical Processing) seperti penghitungan Total Revenue by Region over 12 Months, CPU MySQL akan melonjak naik melebihi 90%.

Dalam arsitektur Enterprise, solusinya sangatlah jelas yaitu Pemisahan beban kerja. Biarkan MySQL menangani transaksi, dan serahkan tugas komputasi analitik kepada Columnar Database khusus untuk analitik seperti ClickHouse. Namun, pertanyaannya adalah "Bagaimana cara memindahkan jutaan baris data per jam dari MySQL ke ClickHouse secara lancar, tanpa mematikan MySQL, dan tanpa membuat data analitik menjadi stale / usang?"

Sejarah Batch ETL

Dahulu, para Software Engineers akan menulis skrip cron job yang berjalan setiap malam jam 2 pagi. Skrip ini akan melakukan SELECT * FROM table WHERE updated_at > last_sync, lalu memindahkannya secara masal ke database sekunder yang disebut dengan istilah Batch ETL.

Pendekatan ini mengandung cacat yaitu:

  1. Table Locks: Kueri masif tersebut sering kali mengunci tabel produksi, menyebabkan transaksi tertunda.
  2. Stale Data: Jika seorang eksekutif membuka dashboard jam 1 siang, data yang mereka lihat adalah data jam 2 pagi. Tidak ada insight real-time.

Arsitektur Change Data Capture (CDC)

Solusi modern untuk menghindari seluruh kerugian di atas adalah meninggalkan pendekatan Query-Based dan beralih ke pendekatan Event-Driven bernama Change Data Capture (CDC). Pendekatan ini tidak bergantung pada pemindaian tabel, melainkan menangkap perubahan data langsung dari sumbernya. Untuk lebih jelasnya, kami pernah membahasnya pada artikel CDC MySQL untuk Real-Time Analytics.

Alih-alih memaksa MySQL memindai tabelnya sendiri, kita "menyadap" aliran log biner (Binary Log atau Binlog) MySQL. Binlog adalah catatan internal berurutan mengenai setiap peristiwa mutasi (INSERT, UPDATE, DELETE) yang terjadi di tingkat cakram (disk).

Arsitektur CDC dari MySQL ke ClickHouse Data Model Architecture: Arsitektur replikasi Zero-Downtime. Mekanisme CDC membaca aliran Binlog MySQL murni secara asinkron dan tidak ada beban kueri SELECT di database utama. Setiap event perubahan seketika ditembakan dan diterima oleh struktur MergeTree ClickHouse.

Dengan mendelegasikan ClickHouse untuk membaca aliran Binlog tersebut, baik secara langsung menggunakan MaterializedMySQL Engine bawaan ClickHouse, atau melalui penengah seperti Kafka dan Debezium, kita mencapai replikasi dengan sub-second latency (latensi di bawah satu detik).

Contoh Implementasi

Mari kita bedah implementasi paling sederhana dan minim infrastruktur, yaitu menggunakan Database Engine hibrida milik ClickHouse, yaitu MaterializedMySQL. Fitur ini menyulap peladen ClickHouse bertindak seolah-olah ia adalah sebuah Read Replica milik MySQL.

1. Konfigurasi MySQL untuk Mengaktifkan Binlog

Pertama, kita harus mengonfigurasi my.cnf pada MySQL agar mengaktifkan Binlog dalam format baris / ROW format.

# /etc/mysql/my.cnf
[mysqld]
server-id=1
log-bin=mysql-bin
binlog_format=ROW # Sangat penting agar CDC bisa membaca perubahan spesifik
gtid_mode=ON
enforce_gtid_consistency=ON

2. Orkestrasi Engine di Sisi ClickHouse

Tanpa perlu tool pihak ketiga, kita masuk ke dalam konsol ClickHouse dan memerintahkannya untuk terintegrasi dengan Binlog MySQL.

-- Dijalankan di dalam ClickHouse
CREATE DATABASE mysql_analytics_replica
ENGINE = MaterializedMySQL(
    'mysql-primary.internal-network.com:3306', -- Host MySQL
    'ecommerce_db',                            -- Nama Database MySQL
    'cdc_user',                                -- User khusus CDC
    'SuperSecretPassword123'                   -- Kata Sandi
);

-- ClickHouse sekarang akan secara otomatis menyedot skema tabel 
-- dan seluruh isinya, lalu mendengarkan Binlog tanpa henti.

Disinilah sulapnya terjadi secara asinkron. Mesin MaterializedMySQL secara diam-diam akan mengonversi mesin penyimpanan InnoDB MySQL menjadi mesin penyimpanan kolumnar ReplacingMergeTree milik ClickHouse di background.

Contoh Kasus Operasional

Kami menangani arsitektur analitik untuk platform e-commerce skala menengah. Dasbor "Live Monitoring" mereka awalnya mengambil data menggunakan JOIN dari 5 tabel berbeda di dalam MySQL InnoDB. Load Time dasbor mencapai 30 detik dan CPU MySQL mencapai 85% setiap kali user melakukan penyegaran halaman.

Dasbor Real-Time OLAP ClickHouse UI System Design: Dasbor Analitik OLAP pasca-migrasi. Metrik 'Ingestion Rate' menunjukkan volume jutaan baris data yang mengalir secara mulus dari MySQL ke ClickHouse. Grafik kompleks kini dirender secara instan berkat sifat analitikal (kolumnar) dari ClickHouse.

Dengan menerapkan pipeline CDC Zero-Downtime di atas:

  1. Dasbor dipindahkan untuk mengambil (Query) data murni dari mesin ClickHouse.
  2. Kecepatan Query agregasi turun dari 30 detik menjadi 40 milidetik. Kecepatan yang tidak masuk akal untuk MySQL, namun merupakan hal biasa bagi ClickHouse.
  3. Beban CPU MySQL InnoDB turun menjadi 15% karena hanya menangani transaksional pengguna.
  4. Yang terpenting adalah Eksekutif bisnis mendapatkan data laporan yang 100% mutakhir secara real-time. Ketika sebuah baris data baru masuk di MySQL, baris tersebut sudah berada di dasbor ClickHouse dalam waktu 200 milidetik kemudian.

Memisahkan operasional (OLTP) dengan analitik (OLAP) adalah cara menuju infrastruktur Enterprise yang efisien. Dengan menggunakana arsitektur Change Data Capture (CDC), kita tidak lagi membebani server dengan mengambil data melalui kueri batch yang merusak performa. Kita mengambil perubahan secara langsung dari Binlog.

Kombinasi antara transaksional MySQL dan analitikal kolumnar ClickHouse menciptakan orkestra arsitektur yang bisa melayani ratusan juta baris data tanpa kehabisan nafas sedikit pun.

Ayoo -- Tetap semangat belajar, bereksplorasi, dan jangan pernah berhenti membangun hal-hal yang luar biasa!

← Back to Blog Index