Zero-Downtime Multi-Region Database Scaling: MySQL Galera Cluster di Belakang HAProxy dan Keepalived

1. Konteks Industri & Analisis Akar Masalah

Dalam lanskap arsitektur web modern, skalabilitas dan ketersediaan tinggi (high availability) bukan lagi sekadar kemewahan, melainkan fondasi mutlak yang menentukan hidup-matinya bisnis digital. Ketika sebuah aplikasi enterprise mengalami lonjakan traffic—baik dari kampanye pemasaran masif, pemrosesan transaksi real-time, maupun ekspansi global—infrastruktur database konvensional yang mengandalkan satu titik kegagalan tunggal (Single Point of Failure atau SPOF) pasti akan runtuh. Kegagalan ini memicu down-time total yang berdampak langsung pada hilangnya pendapatan, rusaknya reputasi merek, dan pelanggaran Service Level Agreement (SLA).

Secara tradisional, arsitektur database relasional seperti MySQL menggunakan pendekatan Master-Slave (Primary-Replica) asinkron. Pendekatan ini memiliki cacat bawaan yang parah: latensi replikasi, risiko kehilangan data (data loss) saat terjadi failover manual jika slave belum sepenuhnya menyerap binary log (binlog) dari master, serta kerumitan dalam mengarahkan beban tulis (write workloads) ke satu node tunggal. Ketika master lumpuh, proses promosi slave sering kali memerlukan intervensi manual atau skrip pemantauan pihak ketiga yang rentan terhadap kondisi split-brain—di mana dua node mengklaim diri sebagai master secara bersamaan, mengakibatkan korupsi data yang fatal.

Sebelum penerapan kluster multi-master yang ditenagai oleh Galera, HAProxy, dan Keepalived, sebuah sistem biasanya menderita:

• Bottleneck Tulis: Seluruh operasi INSERT, UPDATE, dan DELETE terkonsentrasi pada satu node, membatasi kapasitas maksimum sesuai batas spesifikasi vertikal server tersebut.
• Downtime Failover yang Lama: Pemulihan dari kegagalan server database memakan waktu hingga beberapa menit bahkan jam, karena aplikasi harus menunggu DNS dipropagasi ulang atau skrip failover selesai mengeksekusi pemeriksaan kesehatan secara manual.
• Ketidakkonsistenan Sesi Pengguna: Aplikasi web skala enterprise yang menggunakan PHP, Node.js, atau Go sering kali mengalami kegagalan otentikasi atau kehilangan status keranjang belanja (shopping cart) karena koneksi database terputus di tengah transaksi aktif.

Setelah mengimplementasikan arsitektur Zero-Downtime Multi-Region Database Scaling menggunakan MySQL Galera Cluster di balik HAProxy dan Keepalived, perusahaan mendapatkan:

• Aktivitas Multi-Master Sejati: Semua node menerima operasi baca dan tulis secara serentak dengan replikasi sinkron berbasis sertifikasi (certification-based replication).
• Failover Transparan Tanpa Hilang Sesi: HAProxy secara instan mengalihkan lalu lintas ke node yang sehat dalam milidetik, sementara Keepalived memastikan IP virtual (Virtual IP) tetap dapat diakses meskipun server fisik penanggung jawab utama mengalami kegagalan total.
• Skalabilitas Linier: Penambahan kapasitas baca dan tulis dapat dilakukan dengan mudah hanya dengan menambahkan node baru ke dalam kluster Galera tanpa memodifikasi kode aplikasi backend.

2. Konsep Inti & Deep Dive Arsitektur

Arsitektur ini dibangun di atas kombinasi tiga komponen utama yang bekerja secara harmonis: Keepalived untuk redundansi jaringan lapis 3/4, HAProxy untuk load balancing dan health checking cerdas lapis 7, serta MySQL Galera Cluster untuk penyimpanan data multi-master sinkron.

Alur Kerja di Balik Layar (Under the Hood)

1. Klien Web (Nginx/PHP-FPM/Go Backend) mengirimkan query SQL ke alamat IP virtual (Virtual IP / VIP) yang dikelola oleh Keepalived.
2. Keepalived memastikan VIP selalu aktif pada salah satu dari dua node Load Balancer (HAProxy Master/Backup) menggunakan protokol VRRP (Virtual Router Redundancy Protocol).
3. HAProxy menerima koneksi pada VIP tersebut, lalu melakukan evaluasi berdasarkan jenis query (baca vs tulis) atau melakukan pemeriksaan kesehatan menyeluruh (health check) menggunakan skrip kustom.
4. HAProxy meneruskan trafik tulis ke node Galera pertama yang aktif, dan mendistribusikan trafik baca ke seluruh node Galera yang ada untuk menyeimbangkan beban (load distribution).
5. MySQL Galera Cluster memproses transaksi menggunakan replikasi sinkron. Ketika transaksi ditulis ke Node A, Galera melakukan validasi konflik secara paralel sebelum melakukan commit ke seluruh node (Node B dan Node C) secara bersamaan.

+-------------------------------------------------------------------------+
|                        Client Web Applications                          |
|                  (PHP-FPM, Node.js, Go, Nginx, etc.)                    |
+-------------------------------------------------------------------------+
                                     |
                                     v
                  +-------------------------------------+
                  |       Virtual IP (VIP) Keepalived   |
                  |             192.168.10.100          |
                  +-------------------------------------+
                             /                 \
                            /                   \
                           v                     v
         +-------------------------+   +-------------------------+
         |  HAProxy Load Balancer  |   |  HAProxy Load Balancer  |
         |        (Primary)        |   |        (Backup)         |
         +-------------------------+   +-------------------------+
                           \                     /
                            \                   /
                             v                 v
+-------------------------------------------------------------------------+
|                         MySQL Galera Cluster                            |
|                                                                         |
|   +-----------------------+     WSREP     +-----------------------+     |
|   |    MySQL Node 01      | <-------------> |    MySQL Node 02      |     |
|   |    (Active/Write)     |                 |    (Active/Read)      |     |
|   +-----------------------+                 +-----------------------+     |
|               ^                                         ^                 |
|               |                  WSREP                  |                 |
|               +-----------------------------------------+                 |
|                                                                         |
+-------------------------------------------------------------------------+

Sinkronisasi Galera: SST vs IST

• State Snapshot Transfer (SST): Digunakan ketika sebuah node baru bergabung ke kluster atau node yang tertinggal (out-of-sync) terlalu jauh sehingga binary log lokal tidak mencukupi. SST melakukan penyalinan seluruh data dari node donor ke node joiner menggunakan metode seperti rsync, mysqldump, atau xtrabackup.
• Incremental State Transfer (IST): Digunakan ketika node mengalami pemutusan koneksi singkat dan galera mencatat bahwa selisih transaksi masih tersimpan di dalam gcache (Galera Cache) node donor. IST jauh lebih efisien karena hanya mengirimkan delta perubahan transaksi, bukan seluruh isi database.

3. Perbandingan Komparatif / Analisis Pendekatan

Berikut adalah analisis komparatif mendalam antara pendekatan tradisional Master-Slave dengan Galera Multi-Master Cluster di balik HAProxy dan Keepalived.

4. Prasyarat Sistem & Persiapan Lingkungan

Sebelum memulai konfigurasi, pastikan Anda menyiapkan setidaknya 4 unit server (atau Virtual Private Server / VPS) dengan spesifikasi minimum: RAM 4GB, CPU 2 Core, dan sistem operasi Ubuntu 22.04 LTS atau Debian 12 Bookworm yang bersih.

Alokasi IP Server:

• 192.168.10.10 : HAProxy Master (Load Balancer 1)
• 192.168.10.11 : HAProxy Backup (Load Balancer 2)
• 192.168.10.100: Virtual IP (VIP) Keepalived
• 192.168.10.21 : MySQL Galera Node 1
• 192.168.10.22 : MySQL Galera Node 2
• 192.168.10.23 : MySQL Galera Node 3

Persiapan Jaringan & Firewall

Pastikan port-port berikut diizinkan pada firewall (UFW atau iptables) di setiap node:

• Keepalived: Protokol VRRP (IP Protocol 112)
• HAProxy: Port 80 (HTTP), 443 (HTTPS), 3306 (MySQL Proxy), 7000 (Stats Dashboard)
• Galera Cluster: Port 3306 (MySQL client), 4567 (Galera cluster traffic), 4568 (Incremental State Transfer), 4444 (State Snapshot Transfer)

5. Panduan Implementasi Langkah demi Langkah

Langkah 1: Instalasi Paket Dasar pada Node MySQL (192.168.10.21, 22, 23)

Jalankan perintah berikut di semua node database:

sudo apt update && sudo apt upgrade -y
sudo apt install software-properties-common curl -y

# Tambahkan repository resmi MariaDB (yang menyediakan Galera bawaan yang stabil)
sudo apt-key adv --fetch-keys 'https://mariadb.org/mariadb_release_signing_key.asc'
sudo add-apt-repository 'deb [arch=amd64] https://mirror.netcologne.de/mariadb/repo/10.11/ubuntu jammy main'

sudo apt update
sudo apt install mariadb-server mariadb-client rsync -y

sudo systemctl stop mariadb

Langkah 2: Konfigurasi MySQL Galera (/etc/mysql/mariadb.conf.d/60-galera.cnf)

Buat dan sesuaikan file konfigurasi Galera di Node 1 (192.168.10.21). Perhatikan variabel wsrep_node_address yang harus disesuaikan dengan IP masing-masing server.

[mysqld]
binlog_format=ROW
default-storage-engine=innodb
innodb_autoinc_lock_mode=2

# Bind address agar dapat diakses dari jaringan lokal
bind-address=0.0.0.0

# Galera Provider Configuration
wsrep_on=ON
wsrep_provider=/usr/lib/galera/libgalera_smm.so

# Galera Cluster Connection URL
wsrep_cluster_name="enterprise_galera_cluster"
wsrep_cluster_address="gcomm://192.168.10.21,192.168.10.22,192.168.10.23"

# Node Specific Configuration (Ubah IP ini pada Node 2 dan Node 3)
wsrep_node_address="192.168.10.21"
wsrep_node_name="galera-node-01"

# SST Method
wsrep_sst_method=rsync
wsrep_sst_auth="sft_sst_user:SStSecurePassword2024!"

[!IMPORTANT] Pastikan Anda menyalin file konfigurasi ini ke Node 2 dan Node 3, namun ubah parameter wsrep_node_address dan wsrep_node_name sesuai dengan identitas masing-masing node.

Langkah 3: Inisialisasi Kluster Pertama

Bootstrap kluster hanya pada Node 1 (192.168.10.21):

sudo galera_new_cluster

Verifikasi bahwa node telah menjadi bagian dari kluster aktif dengan masuk ke MySQL:

SHOW STATUS LIKE 'wsrep_cluster_size';

Nilai harus menunjukkan angka 1.

Selanjutnya, pada Node 2 dan Node 3, jalankan layanan MySQL secara normal:

sudo systemctl start mariadb

Periksa kembali ukuran kluster dari salah satu node:

SHOW STATUS LIKE 'wsrep_cluster_size';

Nilai harus menunjukkan angka 3.

Langkah 4: Setup Keepalived pada Load Balancer (192.168.10.10 & 192.168.10.11)

Install Keepalived di kedua server HAProxy:

sudo apt install keepalived -y

Konfigurasi Keepalived pada HAProxy Master (/etc/keepalived/keepalived.conf):

vrrp_script check_haproxy {
    script "/usr/bin/killall -0 haproxy"
    interval 2
    weight 2
}

vrrp_instance VI_1 {
    state MASTER
    interface eth0
    virtual_router_id 51
    priority 101
    advert_int 1
    
    authentication {
        auth_type PASS
        auth_pass SecureVRRPKey99!
    }
    
    virtual_ipaddress {
        192.168.10.100/24
    }
    
    track_script {
        check_haproxy
    }
}

Pada HAProxy Backup (192.168.10.11), ubah state BACKUP dan priority 100.

Langkah 5: Konfigurasi HAProxy (/etc/haproxy/haproxy.cfg)

Install HAProxy pada kedua node load balancer:

sudo apt install haproxy -y

Tulis konfigurasi berikut ke /etc/haproxy/haproxy.cfg:

global
    log /dev/log local0
    log /dev/log local1 notice
    chroot /var/lib/haproxy
    user haproxy
    group haproxy
    daemon
    maxconn 4096

defaults
    log     global
    mode    tcp
    option  tcplog
    option  dontlognull
    retries 3
    timeout queue           1m
    timeout connect         10s
    timeout client          30m
    timeout server          30m

# Stats Dashboard
frontend stats
    mode http
    bind 0.0.0.0:7000
    stats enable
    stats uri /
    stats refresh 5s

# MySQL Write Frontend (Active-Passive node selection)
frontend mysql_write_front
    bind 192.168.10.100:3306
    mode tcp
    default_backend mysql_write_back

backend mysql_write_back
    mode tcp
    balance roundrobin
    option httpchk GET /health
    http-check expect status 200
    default-server inter 3s rise 2 fall 3
    server galera-01 192.168.10.21:3306 check port 9200 maxconn 500
    server galera-02 192.168.10.22:3306 check port 9200 backup maxconn 500
    server galera-03 192.168.10.23:3306 check port 9200 backup maxconn 500

[!TIP] Gunakan HTTP check daemon ringan seperti clustercheck (disediakan oleh Percona/MariaDB) di setiap node database pada port 9200 agar HAProxy dapat mendeteksi apakah sebuah node benar-benar siap melayani query atau sedang dalam status Desynced/Non-Operational.

6. Bedah Kode & Penjelasan Detail Baris Kunci

• binlog_format=ROW Sangat krusial dalam Galera. Replikasi berbasis row-based menjamin bahwa perubahan baris data secara aktual yang disebarkan ke node lain, bukan pernyataan SQL mentah yang dapat menghasilkan hasil berbeda akibat fungsi non-deterministik seperti NOW() atau RAND().

• innodb_autoinc_lock_mode=2 Mengaktifkan interleaved lock mode. Ini memungkinkan beberapa node menghasilkan nilai auto-increment secara bersamaan tanpa saling mengunci tabel secara global, mencegah hambatan performa (performance bottleneck) pada operasi tulis konkuren tinggi.

• wsrep_cluster_address="gcomm://..." Daftar benih (seed list) node yang digunakan oleh Galera untuk menemukan anggota kluster saat pertama kali diinisialisasi. Jika satu node mati, node yang tersisa menggunakan daftar ini untuk merekonsiliasi keanggotaan.

• option httpchk GET /health pada HAProxy Memaksa HAProxy untuk memvalidasi kesehatan node database melalui HTTP probe. Jika server database mengalami deadlock atau kehabisan memori, skrip kesehatan akan mengembalikan status selain 200 OK, dan HAProxy secara otomatis mengeluarkan node tersebut dari rotasi trafik.

7. Skenario Produksi & Studi Kasus Dunia Nyata

Dalam sebuah platform e-commerce enterprise dengan rata-rata 15.000 permintaan per detik (requests per second) selama acara Flash Sale, kegagalan database tunggal akan mengakibatkan kerugian finansial masif.

Implementasi Skenario Beban Tinggi:

1. Pemisahan Beban (Read/Write Splitting): Aplikasi backend PHP/Laravel dikonfigurasi menggunakan dua koneksi database: DB_WRITE_HOST mengarah ke Virtual IP HAProxy pada port tulis, dan DB_READ_HOST mengarahkan query laporan atau pencarian produk ke port baca round-robin yang mencakup seluruh node Galera.
2. Manajemen Koneksi Persisten: Menggunakan ProxySQL atau pengelolaan connection pooling yang ketat di tingkat aplikasi untuk mencegah lonjakan pembukaan koneksi baru (connection storms) yang dapat melumpuhkan utas (threads) MySQL.
3. Optimasi gcache: Variabel gcache.size ditingkatkan menjadi 1G (1 Gigabyte) di file 60-galera.cnf untuk memastikan node yang mengalami gangguan jaringan singkat selama 10-15 menit dapat melakukan pemulihan secara cepat melalui IST tanpa harus memicu SST yang membebani I/O disk secara masif.

8. Common Pitfalls, Anti-Patterns & Solusi

• Anti-Pattern 1: Kluster Genap (2 Node) Masalah: Mengonfigurasi kluster Galera dengan 2 node. Jika salah satu node mati, kluster kehilangan kuorum (memerlukan minimal mayoritas: $N/2 + 1$). Sisa 1 node akan menolak semua transaksi tulis. Solusi: Selalu gunakan jumlah node ganjil (minimal 3 node), atau gunakan Galera Arbitrator (garbd) pada server pihak ketiga ketiga untuk menjaga kuorum tanpa membebani memori database.

• Anti-Pattern 2: Mengabaikan Timeout Koneksi Aplikasi Masalah: Aplikasi web tidak mengatur waktu tunggu (timeout) koneksi saat terjadi transisi failover milidetik, menyebabkan ribuan eksepsi mysqli_sql_exception menumpuk di log PHP. Solusi: Terapkan pola Exponential Backoff & Retry pada lapisan kode ORM (seperti Eloquent atau GORM) untuk menangani jeda mikrosekon saat HAProxy mengalihkan koneksi.

• Anti-Pattern 3: Tabel Tanpa Primary Key Masalah: Galera memerlukan Primary Key pada setiap tabel InnoDB untuk melakukan replikasi baris secara efisien. Tabel tanpa Primary Key akan memicu full table scan internal yang menghancurkan performa kluster. Solusi: Terapkan CI/CD linters atau aturan migrasi database yang melarang pembuatan tabel tanpa kolom Primary Key yang valid.

9. Benchmark, Metrik Kinerja & Tuning Performa

Pengujian beban dilakukan menggunakan perangkat sysbench untuk mensimulasikan transaksi OLTP konkuren tinggi pada kluster Galera 3-node.

Perintah Benchmark Sysbench:

# Persiapan data uji
sysbench /usr/share/sysbench/oltp_read_write.lua \
  --mysql-host=192.168.10.100 \
  --mysql-port=3306 \
  --mysql-user=root \
  --mysql-password=SecurePassword \
  --table-size=1000000 \
  --tables=10 prepare

# Eksekusi benchmark beban tinggi selama 5 menit
sysbench /usr/share/sysbench/oltp_read_write.lua \
  --mysql-host=192.168.10.100 \
  --mysql-port=3306 \
  --mysql-user=root \
  --mysql-password=SecurePassword \
  --table-size=1000000 \
  --tables=10 \
  --threads=100 \
  --time=300 \
  --report-interval=10 run

Interpretasi Metrik & Tuning Parameter Lanjutan:

• Transactions Per Second (TPS): Jika nilai TPS menurun drastis seiring penambahan thread, periksa antrian sertifikasi (wsrep_cert_deps_distance). Nilai jarak dependensi yang rendah mengindikasikan tingginya konflik transaksi pada baris data yang sama.
• Tuning InnoDB Buffer Pool: Atur innodb_buffer_pool_size hingga 70-80% dari total RAM fisik pada server database.
• Tuning Jaringan: Optimalkan parameter kernel Linux di /etc/sysctl.conf untuk menangani buffer jaringan berkecepatan tinggi:

  net.core.rmem_max = 16777216
  net.core.wmem_max = 16777216
  net.ipv4.tcp_rmem = 4096 87380 16777216
  net.ipv4.tcp_wmem = 4096 65536 16777216
  

10. Checklist Penerapan Produksi & Kesimpulan

Gunakan checklist komprehensif berikut sebelum merilis arsitektur ini ke lingkungan produksi:

• Jumlah node kluster ganjil (minimal 3 node) atau menggunakan Arbitrator untuk mencegah kehilangan kuorum.
• Seluruh tabel database dijamin memiliki Primary Key.
• Konfigurasi gcache.size disesuaikan (minimal 1GB) untuk mendukung Incremental State Transfer (IST).
• Keepalived VRRP dikonfigurasi dengan autentikasi sandi yang kuat dan prioritas yang benar.
• Skrip kesehatan HAProxy (health check) teruji mampu memisahkan node yang mengalami kegagalan secara instan.
• Mekanisme backup otomatis harian menggunakan Percona XtraBackup berjalan secara independen tanpa membebani sinkronisasi kluster.
• Pemantauan metrik (Prometheus + Grafana) diaktifkan untuk memantau wsrep_cluster_status, wsrep_local_send_queue, dan wsrep_local_recv_queue.

Dengan menerapkan arsitektur MySQL Galera Cluster di balik HAProxy dan Keepalived secara cermat, organisasi Anda tidak hanya mencapai ketersediaan tingkat tinggi (high availability) mutlak dengan zero downtime, tetapi juga membangun fondasi infrastruktur database yang tangguh, aman, dan siap menghadapi pertumbuhan skala enterprise di masa depan.