Arsitektur High Availability & Database Clustering Menggunakan MariaDB Galera

1. Konteks Industri & Analisis Akar Masalah

Dalam lanskap arsitektur web modern, skalabilitas dan ketersediaan tinggi (High Availability / HA) bukan lagi fitur opsional, melainkan fondasi bisnis yang mutlak. Ketika sebuah platform aplikasi enterprise menghadapi lonjakan jutaan concurrent users—baik itu platform e-commerce saat kampanye flash sale, layanan finansial real-time, atau SaaS enterprise—infrastruktur database sering kali menjadi bottleneck utama yang memicu kegagalan sistem secara menyeluruh (Single Point of Failure atau SPOF).

Secara tradisional, arsitektur database relasional seperti MySQL atau MariaDB menggunakan model Primary-Replica (Master-Slave asynchronous atau semi-synchronous). Meskipun model ini efektif untuk memisahkan beban baca (read scaling), ia memiliki kelemahan struktural yang fatal pada skenario tulis (write scaling). Ketika Primary node mengalami kegagalan perangkat keras, jaringan terputus, atau corrupt, sistem memerlukan proses failover manual atau otomatis menggunakan orkestrator eksternal (seperti MHA, Orchestrator, atau Keepalived). Proses ini sering kali memicu split-brain syndrome, downtime layanan selama beberapa menit hingga jam, serta risiko kehilangan data (data loss) akibat replikasi asynchronous yang belum tuntas.

Perbandingan Kondisi: Sebelum vs Sesudah Penerapan MariaDB Galera Cluster

Dengan menerapkan MariaDB Galera Cluster, kita mengeliminasi SPOF pada lapisan database, memastikan konsistensi data yang ketat di seluruh node, dan memungkinkan arsitektur aplikasi backend (seperti PHP-FPM, Node.js, atau Go) melakukan operasi tulis dan baca secara terdistribusi tanpa kekhawatiran inkonsistensi replikasi.

2. Konsep Inti & Deep Dive Arsitektur

MariaDB Galera Cluster adalah implementasi synchronous multi-master cluster untuk MariaDB, yang ditenagai oleh Galera Replication Library menggunakan protokol WSREP (Write Set Replication). Berbeda dengan replikasi tradisional yang memindahkan statement atau row events secara asynchronous, Galera mereplikasi write-sets yang berisi baris data yang telah dimodifikasi bersama dengan tanda tangan transaksinya.

Alur Kerja di Balik Layar (Under the Hood)

1. Inisiasi Transaksi (Local Execution): Aplikasi mengirimkan query BEGIN, INSERT/UPDATE/DELETE, hingga COMMIT ke salah satu node di dalam kluster.
2. Replikasi Write-Set: Sebelum transaksi di-commit secara lokal ke penyimpanan disk (InnoDB storage engine), node tersebut mengenkapsulasi perubahan data ke dalam write-set dan menyiarkannya (broadcast) ke seluruh node lain di dalam kluster melalui protokol grup komunikasi multicast/unicast.
3. Certification (Certification-based Replication): Setiap node menerima write-set tersebut dan melakukan proses certification secara paralel. Proses ini memeriksa apakah ada konflik baris data dengan transaksi lain yang sedang berjalan secara konkuren. Jika tidak ada konflik, write-set dianggap valid.
4. Commit & Rollback: Jika lolos sertifikasi, transaksi di-commit di semua node. Jika terjadi konflik (misalnya dua transaksi mengubah baris yang sama secara bersamaan), transaksi dengan sertifikasi terlambat akan otomatis dibatalkan (rollback) dan memicu deadlock error yang harus ditangani oleh aplikasi.

+-------------+          +-------------+          +-------------+
|   App /     |          |   App /     |          |   App /     |
|  Load Bal.  |          |  Load Bal.  |          |  Load Bal.  |
+------+------+          +------+------+          +------+------+
       |                        |                        |
       v                        v                        v
+------+------+          +------+------+          +------+------+
|   Node 1    |<=======>|   Node 2    |<=======>|   Node 3    |
| (Multi-Master)        | (Multi-Master)        | (Multi-Master)
+-------------+          +-------------+          +-------------+
       ^                        ^                        ^
       +------------------------+------------------------+
                    WSREP Replication Protocol
         (Total Order Isolation & Certification-based)

[!IMPORTANT] Galera Cluster menerapkan prinsip Total Order Isolation (TOI). Artinya, DDL (Data Definition Language) seperti ALTER TABLE dieksekusi secara sinkron di seluruh node dengan mengunci tabel secara global. Hindari eksekusi DDL skala besar pada jam puncak traffic.

3. Perbandingan Komparatif / Analisis Pendekatan

Untuk merancang infrastruktur high availability yang optimal, kita harus memahami trade-off antara Galera Cluster dengan alternatif arsitektur database lainnya.

[!TIP] Jangan pernah menjalankan Galera Cluster dengan jumlah node genap (misal 2 atau 4 node) tanpa Arbitrator (GarBD). Jika terjadi putusnya jaringan (network partition), kluster memerlukan kuorum mayoritas ($N/2 + 1$) untuk mencegah split-brain. 3 node adalah standar minimum untuk enterprise production.

4. Prasyarat Sistem & Persiapan Lingkungan

Sebelum melakukan instalasi MariaDB Galera Cluster, pastikan lingkungan infrastruktur memenuhi spesifikasi teknis berikut:

Spesifikasi Minimum Environment (Production)

• OS: Ubuntu 22.04 LTS / Debian 12 / Rocky Linux 9
• Node: 3 Unit Server (Contoh IP: 192.168.1.101, 192.168.1.102, 192.168.1.103)
• RAM: Minimal 4GB per node (disarankan SSD NVMe untuk performa I/O redo log)
• Jaringan: Koneksi internal privat berkecepatan tinggi (< 2ms antar node)

Konfigurasi Firewall & Port Jaringan

Galera memerlukan beberapa port jaringan yang harus dibuka pada sistem firewall (ufw atau firewalld):

• 3306/tcp: Port standar MariaDB untuk klien SQL.
• 4567/tcp: Port replikasi Galera Cluster (WSREP traffic).
• 4568/tcp: Port untuk State Snapshot Transfer (SST) incremental.
• 4444/tcp: Port untuk State Snapshot Transfer (SST) penuh (rsync/mysqldump/mariabackup).

5. Panduan Implementasi Langkah demi Langkah

Ikuti langkah-langkah berikut untuk membangun kluster MariaDB Galera 3-node di atas sistem operasi Ubuntu 22.04 LTS.

Langkah 1: Instalasi MariaDB Server di Semua Node

Jalankan perintah berikut pada ketiga node (node1, node2, node3):

sudo apt update
sudo apt install -y software-properties-common curl
sudo curl -LsS https://downloads.mariadb.com/MariaDB/mariadb_repo_setup | sudo bash -s -- --mariadb-server-version=10.11
sudo apt update
sudo apt install -y mariadb-server mariadb-client rsync galera-4

Langkah 2: Konfigurasi MariaDB Galera (Server 1 - 192.168.1.101)

Hentikan layanan MariaDB terlebih dahulu, lalu buat file konfigurasi khusus Galera di /etc/mysql/mariadb.conf.d/65-galera.cnf:

sudo systemctl stop mariadb

Buat dan isi file /etc/mysql/mariadb.conf.d/65-galera.cnf dengan konfigurasi berikut:

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

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

# Galera Cluster Cluster Address
wsrep_cluster_address="gcomm://192.168.1.101,192.168.1.102,192.168.1.103"

# Cluster Name
wsrep_cluster_name="production-galera-cluster"

# Node Specific Configuration (Ubah IP sesuai node masing-masing)
wsrep_node_address="192.168.1.101"
wsrep_node_name="galera-node-01"

# SST Method (Gunakan mariabackup untuk performa enterprise)
wsrep_sst_method=mariabackup
wsrep_sst_auth="sstuser:SSTSecurePassword123!"

Langkah 3: Konfigurasi MariaDB Galera (Server 2 & 3)

Lakukan konfigurasi serupa pada node2 (192.168.1.102) dan node3 (192.168.1.103), namun sesuaikan parameter wsrep_node_address dan wsrep_node_name:

Untuk Node 2 (192.168.1.102):

wsrep_node_address="192.168.1.102"
wsrep_node_name="galera-node-02"

Untuk Node 3 (192.168.1.103):

wsrep_node_address="192.168.1.103"
wsrep_node_name="galera-node-03"

Langkah 4: Bootstrap Kluster Pertama Kali

Bootstrap hanya dilakukan sekali pada Node Pertama (192.168.1.101) untuk menginisialisasi bootstrap cluster baru:

sudo galera_new_cluster

Verifikasi bahwa kluster telah berjalan dan mendeteksi 1 node aktif:

sudo mysql -u root -e "SHOW STATUS LIKE 'wsrep_cluster_size';"

Output yang diharapkan:

+--------------------+-------+
| Variable_name      | Value |
+--------------------+-------+
| wsrep_cluster_size | 1     |
+--------------------+-------+

Langkah 5: Bergabung ke Kluster pada Node 2 dan Node 3

Pada node2 dan node3, jalankan layanan MariaDB secara normal (tanpa galera_new_cluster):

sudo systemctl start mariadb

Kembali ke node1 atau periksa di semua node untuk memastikan ukuran kluster telah meningkat menjadi 3:

sudo mysql -u root -e "SHOW STATUS LIKE 'wsrep_cluster_size';"

Output yang diharapkan:

+--------------------+-------+
| Variable_name      | Value |
+--------------------+-------+
| wsrep_cluster_size | 3     |
+--------------------+-------+

6. Bedah Kode & Penjelasan Detail Baris Kunci

Mari kita bedah parameter penting dalam file konfigurasi 65-galera.cnf yang menentukan stabilitas sistem:

• binlog_format=ROW: Galera wajib menggunakan format berbasis baris (row-based binary logging). Format statement atau mixed tidak didukung karena replikasi write-set membutuhkan data aktual per baris yang diubah untuk proses sertifikasi.
• innodb_autoinc_lock_mode=2: Mengatur mode kunci auto-increment menjadi interleaved lock mode. Hal ini sangat krusial untuk performa multi-master agar operasi INSERT konkuren dari berbagai node tidak saling mengunci tabel secara berurutan (table-level locking), sehingga mencegah penurunan throughput.
• wsrep_provider=/usr/lib/galera/libgalera_sstr.so: Menunjuk path absolut ke pustaka WSREP Galera yang menangani komunikasi antar node, manajemen keanggotaan kluster, dan algoritma state machine.
• wsrep_cluster_address="gcomm://...": Daftar benih (seed list) IP node lain dalam kluster. Saat sebuah node dinyalakan, ia akan mencoba menghubungi IP-IP ini untuk menemukan kluster yang aktif.
• wsrep_sst_method=mariabackup: Metode transfer State Snapshot menggunakan mariabackup. Metode ini jauh lebih aman dan efisien dibandingkan mysqldump karena melakukan hot backup tanpa mengunci tabel, serta lebih cepat dibanding rsync untuk database berukuran besar.

7. Skenario Produksi & Studi Kasus Dunia Nyata

Dalam arsitektur web modern berstandar enterprise, MariaDB Galera Cluster biasanya dipadukan dengan Load Balancer TCP tingkat lanjut seperti HAProxy atau ProxySQL pada lapisan aplikasi backend (PHP-FPM/Go/Node.js).

Arsitektur High Availability Lengkap:

[ Web Clients ] ---> [ Cloudflare CDN / WAF ]
                           |
                           v
              [ Nginx Reverse Proxy / SSL Term ]
                           |
                           v
        [ Backend Application (PHP-FPM / Go / Node) ]
                           |
                           v
           [ HAProxy / ProxySQL Load Balancer ]
            /              |              \
           v               v               v
     [ MariaDB ]     [ MariaDB ]     [ MariaDB ]
     (Node 1 - RW)   (Node 2 - RW)   (Node 3 - RW)

Konfigurasi Dasar HAProxy untuk Galera Health Check

Untuk mencegah aplikasi mengirimkan query ke node MariaDB yang sedang down atau keluar dari kuorum, kita dapat mengonfigurasi HAProxy dengan pemeriksaan kesehatan (health check) berbasis port khusus MariaDB atau menggunakan skrip pihak ketiga (clustercheck).

Contoh konfigurasi haproxy.cfg untuk load balancing Galera Cluster:

global
    log /dev/log local0
    maxconn 4096

defaults
    log global
    option tcplog
    option dontlognull
    retries 3
    timeout connect 5s
    timeout client  50s
    timeout server  50s

frontend mariadb_front
    bind *:3306
    mode tcp
    default_backend mariadb_back

backend mariadb_back
    mode tcp
    balance roundrobin
    option tcp-check
    # Health check mendeteksi apakah node berstatus Synced (wsrep_local_state = 4)
    server node1 192.168.1.101:3306 check inter 2s rise 2 fall 3
    server node2 192.168.1.102:3306 check inter 2s rise 2 fall 3
    server node3 192.168.1.103:3306 check inter 2s rise 2 fall 3

[!WARNING] Load balancing TCP murni pada port 3306 melalui HAProxy dapat berisiko jika aplikasi melakukan transaksi panjang atau multi-statement tanpa penanganan error yang tepat. Untuk enterprise berskala besar, sangat disarankan menggunakan ProxySQL karena ia memahami protokol MySQL, mampu melakukan query routing (membaca ke replica, menulis ke master), serta connection pooling.

8. Common Pitfalls, Anti-Patterns & Solusi

Dalam pengalaman operasional mengelola infrastruktur production berskala besar, berikut adalah kesalahan fatal yang sering dilakukan oleh sysadmin dan backend engineer:

1. Menggunakan Tabel Tanpa Primary Key (MyISAM / InnoDB Non-PK):

   • Anti-Pattern: Membuat tabel tanpa Primary Key di Galera Cluster.
   • Dampak: Galera memerlukan Primary Key untuk mengidentifikasi baris data secara unik saat proses certification. Tabel tanpa PK akan memicu peringatan, replikasi tidak efisien, dan berisiko tinggi menyebabkan desync antar node.
   • Solusi: Selalu pastikan setiap tabel memiliki PRIMARY KEY yang tegas sebelum masuk ke produksi.

2. Menjalankan Operasi Tulis Konkuren Tinggi pada Baris yang Sama (Hotspot Rows):

   • Anti-Pattern: Desain tabel saldo atau counter global yang di-update jutaan kali per detik pada baris yang sama dari berbagai node.
   • Dampak: Menyebabkan tingkat certification failure yang masif, tingginya deadlock, dan penurunan performa drastis karena rollback terus-menerus.
   • Solusi: Lakukan sharding logis, gunakan antrean Redis untuk agregasi counter sebelum di-flush ke MariaDB, atau rancang ulang skema database.

3. Mengabaikan Pemantauan Quorum Saat Maintenance Server:

   • Anti-Pattern: Mematikan 2 node secara bersamaan dari kluster 3-node untuk reboot kernel.
   • Dampak: Hilangnya kuorum mayoritas ($N/2 + 1$), sehingga node yang tersisa menolak semua koneksi tulis untuk mencegah korupsi data.
   • Solusi: Lakukan rolling maintenance satu per satu. Pastikan node pertama selesai dan sinkron sebelum melanjutkan ke node berikutnya.

9. Benchmark, Metrik Kinerja & Tuning Performa

Untuk mengukur kesiapan kluster menghadapi beban tinggi, gunakan tool benchmark standar industri seperti sysbench.

Perintah Pengujian Benchmark Sysbench

1. Inisialisasi Data Uji:

   sysbench /usr/share/sysbench/oltp_read_write.lua \
     --mysql-host=192.168.1.101 \
     --mysql-user=root \
     --mysql-password=YourRootPassword \
     --mysql-db=test \
     --table-size=1000000 \
     --tables=10 prepare
   

2. Menjalankan Beban Kerja (Load Test):

   sysbench /usr/share/sysbench/oltp_read_write.lua \
     --mysql-host=192.168.1.101 \
     --mysql-user=root \
     --mysql-password=YourRootPassword \
     --mysql-db=test \
     --table-size=1000000 \
     --tables=10 \
     --threads=64 \
     --time=60 \
     --report-interval=10 run
   

Metrik Kunci yang Harus Dipantau (Monitoring):

• wsrep_local_send_queue & wsrep_local_recv_queue: Jika nilai antrean ini sering di atas 0, berarti jaringan atau CPU mengalami saturasi dalam mengirim/menerima write-set.
• wsrep_cert_failures: Jumlah transaksi yang gagal akibat konflik sertifikasi. Nilai yang tinggi menunjukkan adanya desain aplikasi yang memicu hotspot contention.
• wsrep_cluster_status: Pastikan status selalu bernilai Primary.

10. Checklist Penerapan Produksi & Kesimpulan

Sebelum meluncurkan kluster MariaDB Galera ke lingkungan live production, pastikan Anda telah menyelesaikan checklist verifikasi berikut:

• Minimum 3 node aktif dengan latensi jaringan privat < 2ms.
• Seluruh port firewall (3306, 4567, 4568, 4444) terkonfigurasi dengan benar.
• Metode SST menggunakan mariabackup dengan kredensial enkripsi yang kuat.
• Setiap tabel di database memiliki PRIMARY KEY yang valid.
• Implementasi ProxySQL atau HAProxy untuk manajemen koneksi dan health check aplikasi.
• Pengujian simulasi network partition (split-brain test) dan node failure recovery berhasil dilakukan.
• Sistem monitoring (Prometheus + Grafana + MariaDB Exporter) aktif memantau metrik WSREP.

Dengan mengikuti panduan komprehensif ini, Anda kini memiliki fondasi arsitektur database multi-master berkinerja tinggi, tahan banting terhadap kegagalan perangkat keras, serta siap menopang lonjakan traffic aplikasi enterprise secara seamless.