Desain High Availability Database dengan Galera Cluster MariaDB

1. Konteks Industri & Analisis Akar Masalah

Dalam lanskap arsitektur sistem web modern yang menuntut ketersediaan tinggi (high availability) dan konsistensi data yang mutlak, kegagalan database adalah ancaman terbesar yang dapat melumpuhkan seluruh lini bisnis. Sistem transaksional seperti e-commerce, perbankan digital, dan aplikasi SaaS skala enterprise tidak lagi mentolerir downtime yang disebabkan oleh pemeliharaan server, kegagalan perangkat keras, atau lonjakan traffic yang tidak terduga. Pendekatan tradisional seperti arsitektur Primary-Replica (Master-Slave) asinkronik memiliki kelemahan mendasar: adanya replication lag dan risiko hilangnya data (data loss) saat primary node mendadak crash, yang berujung pada proses failover manual atau otomatis yang memakan waktu (Recovery Time Objective / RTO yang tinggi).

Sebelum penerapan Galera Cluster MariaDB, insiden kegagalan server database sering kali mengakibatkan:

• Split-Brain Syndrome: Dua node mengira diri mereka adalah primary dan menerima tulis data secara bersamaan, menyebabkan korupsi data yang parah.
• Downtime Signifikan: Proses promosi replica sekunder menjadi primary membutuhkan waktu intervensi manual, menghentikan seluruh proses transaksi (Transactional Processing).
• Bottleneck Tulis (Write Bottleneck): Keterbatasan satu node tulis membatasi skalabilitas horizontal aplikasi backend berbasis PHP, Go, atau Node.js yang mengirimkan ribuan queries per detik.

Sesudah penerapan klaster multi-master sinkronik berbasis Galera, sistem mendistribusikan beban kerja baca (read) ke seluruh node, sementara proses tulis divalidasi secara serentak (certification-based replication). Jika satu node mati, node lainnya mengambil alih tanpa kehilangan data dan tanpa jeda waktu failover yang berarti, menjamin Zero Data Loss (RPO = 0) dan High Availability mutlak.

2. Konsep Inti & Deep Dive Arsitektur

Galera Cluster adalah solusi penyimpanan multi-master sinkronik untuk MariaDB yang dibangun di atas teknologi certification-based replication. Berbeda dengan replikasi tradisional yang mengirimkan pernyataan SQL atau row events secara asinkron setelah transaksi dikomit, Galera mereplikasi transaksi pada fase commit.

Alur Kerja di Balik Layar (Under the Hood)

1. Local Execution: Aplikasi mengirimkan transaksi ke node lokal.
2. Write-Set Generation: Node lokal mengeksekusi transaksi hingga fase commit, lalu mengumpulkan semua perubahan baris menjadi satu paket data biner yang disebut Write-Set.
3. Broadcasting (Group Communication Framework - GCS): Write-set disiarkan ke seluruh node lain dalam klaster menggunakan protokol komunikasi kelompok yang dioptimalkan (Galera gcache).
4. Certification Test: Setiap node menerima write-set dan melakukan uji sertifikasi secara independen (deterministic validation). Pengujian ini memeriksa apakah ada konflik baris dengan transaksi lain yang sedang berjalan secara bersamaan (concurrent transactions).
5. Commit / Rollback: Jika lolos uji sertifikasi, transaksi dikomit di semua node. Jika terjadi konflik, transaksi yang datang kemudian dibatalkan (rollback) secara otomatis pada node asalnya.

+-------------------------------------------------------------+
|                        Client Application                   |
+-------------------------------------------------------------+
              | (Reads/Writes)                  | (Reads)
              v                                 v
+---------------------------+     +---------------------------+
|      MariaDB Node 1       |     |      MariaDB Node 2       |
|   (Galera Multi-Master)   | <-> |   (Galera Multi-Master)   |
+---------------------------+     +---------------------------+
              ^                                 ^
              |       Galera GCS Replication    |
              +---------------------------------+
                                ^
                                |
                  +---------------------------+
                  |      MariaDB Node 3       |
                  |   (Galera Multi-Master)   |
                  +---------------------------+

3. Perbandingan Komparatif / Analisis Pendekatan

Untuk memahami mengapa Galera Cluster dipilih dalam arsitektur enterprise, mari kita bandingkan dengan dua pendekatan replikasi database MariaDB/MySQL lainnya.

4. Prasyarat Sistem & Persiapan Lingkungan

Sebelum melakukan instalasi, pastikan lingkungan infrastruktur Anda memenuhi standar produksi yang ketat:

• Minimal Node: 3 node server (wajib ganjil untuk menghindari split-brain via mekanisme Quorum).
• Sistem Operasi: Ubuntu Server 22.04 LTS / 24.04 LTS atau Rocky Linux 9.
• Jaringan: IP statis, port internal terbuka secara penuh antar node (Port TCP: 3306 untuk SQL, 4567 untuk Galera Cluster replication, 4568 untuk Incremental State Transfer / IST, 4444 untuk State Snapshot Transfer / SST).
• Sinkronisasi Waktu: NTP / Chrony wajib aktif di seluruh node untuk menghindari deviasi waktu transaksi (clock drift).

Verifikasi awal konektivitas antar node:

ncat -zv <IP_NODE_LAIN> 4567

5. Panduan Implementasi Langkah demi Langkah

Langkah-langkah ini diasumsikan menggunakan Ubuntu 22.04 LTS dan MariaDB 10.11 LTS.

Step 1: Instalasi MariaDB & Galera Package di Semua Node

Jalankan perintah berikut pada Node 1, Node 2, dan Node 3:

sudo apt update
sudo apt install -y software-properties-common curl
sudo apt install -y mariadb-server mariadb-client galera-4

Step 2: Konfigurasi MariaDB & Galera (Node 1)

Edit file konfigurasi /etc/mysql/mariadb.conf.d/60-galera.cnf pada Node 1 dengan konfigurasi produksi berikut:

[mysqld]
bind-address = 0.0.0.0
default-storage-engine = InnoDB
innodb_autoinc_lock_mode = 2
innodb_flush_log_at_trx_commit = 2

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

# Galera Cluster Connection URL
wsrep_cluster_address = "gcache://<IP_NODE_1>,<IP_NODE_2>,<IP_NODE_3>"
wsrep_cluster_name = "production_galera_cluster"

# Node Identification
wsrep_node_address = "<IP_NODE_1>"
wsrep_node_name = "db-node-01"

# SST (State Snapshot Transfer) Method
wsrep_sst_method = rsync
wsrep_sst_auth = "sst_user:SSTSecurePassword123!"

(Ulangi konfigurasi ini untuk Node 2 dan Node 3, sesuaikan wsrep_node_address dan wsrep_node_name).

Step 3: Bootstrap Klaster pada Node Pertama

Hentikan layanan MariaDB di semua node terlebih dahulu:

sudo systemctl stop mariadb

Lakukan bootstrap secara eksklusif hanya pada Node 1:

sudo galera_new_cluster

Verifikasi bahwa klaster telah berjalan dan ukuran klaster adalah 1:

SHOW STATUS LIKE 'wsrep_cluster_size';

Step 4: Bergabung dengan Node 2 dan Node 3

Pada Node 2 dan Node 3, jalankan layanan MariaDB secara normal:

sudo systemctl start mariadb

Periksa kembali ukuran klaster dari salah satu node:

SHOW STATUS LIKE 'wsrep_cluster_size';

Jika konfigurasi benar, output akan menunjukkan angka 3.

6. Bedah Kode & Penjelasan Detail Baris Kunci

• innodb_autoinc_lock_mode = 2: Menggunakan mode interleaved lock. Parameter ini wajib diatur ke 2 agar klaster dapat menangani operasi INSERT paralel dari multi-master tanpa mengalami penguncian tabel (table-level locking) yang merusak performa.
• innodb_flush_log_at_trx_commit = 2: Meningkatkan performa I/O disk secara drastis dengan menulis log transaksi ke memori setiap detik, bukan setiap kali commit fisik disk terjadi.
• wsrep_cluster_address: Menentukan alamat IP semua anggota klaster. Penggunaan format gcache:// mengalokasikan memori khusus untuk menyimpan riwayat write-set agar node yang mengalami drop koneksi singkat dapat melakukan Incremental State Transfer (IST) tanpa SST penuh.
• wsrep_sst_method = rsync: Menentukan metode transfer snapshot awal saat node baru bergabung menggunakan utilitas rsync. Alternatif enterprise yang lebih aman adalah menggunakan mariabackup.

7. Skenario Produksi & Studi Kasus Dunia Nyata

Dalam arsitektur web modern yang melayani sistem e-commerce berskala besar dengan framework backend seperti Go atau Node.js, aplikasi sering kali mengirimkan ribuan transaksi per detik. Tanpa load balancer, aplikasi akan mengalami kegagalan koneksi jika satu node down.

Untuk mengatasi hal ini, kita menempatkan HAProxy di depan klaster Galera untuk mendistribusikan traffic pembacaan (read) dan penulisan (write).

Konfigurasi /etc/haproxy/haproxy.cfg untuk Load Balancing MariaDB:

global
    log /dev/log local0
    maxconn 4096
    user haproxy
    group haproxy
    daemon

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

frontend mariadb_front
    bind *:3306
    mode tcp
    default_backend mariadb_cluster

backend mariadb_cluster
    mode tcp
    balance roundrobin
    option httpchk GET /health
    http-check expect status 200
    default-server inter 3s fall 3 rise 2
    server db-node-01 <IP_NODE_1>:3306 check port 9200
    server db-node-02 <IP_NODE_2>:3306 check port 9200
    server db-node-03 <IP_NODE_3>:3306 check port 9200

[!TIP] Gunakan skrip pemeriksaan kesehatan (health check script) seperti clustercheck yang mendengarkan pada port 9200 untuk memastikan HAProxy hanya meneruskan traffic ke node MariaDB yang berstatus Synced dan siap melayani transaksi.

8. Common Pitfalls, Anti-Patterns & Solusi

1. Melakukan Bootstrap pada Lebih dari Satu Node Secara Bersamaan:

   • Anti-Pattern: Menjalankan galera_new_cluster di Node 1 dan Node 2 secara terpisah setelah pemadaman listrik total.
   • Dampak: Terjadi split-brain dengan dua UUID klaster yang berbeda, merusak konsistensi data.
   • Solusi: Tentukan primary component secara manual dengan memeriksa file grastate.dat pada node yang memiliki seqno (sequence number) tertinggi.

2. Menggunakan Jumlah Node Genap (2 atau 4 Node):

   • Anti-Pattern: Membangun klaster dengan 2 node untuk menghemat biaya server.
   • Dampak: Jika satu node terputus, klaster kehilangan kuorum mayoritas (50%-50%), membuat klaster menolak semua transaksi tulis demi keamanan.
   • Solusi: Selalu gunakan jumlah node ganjil minimal 3, atau gunakan Galera Arbitrator (garbd) sebagai penengah kuorum ketiga.

9. Benchmark, Metrik Kinerja & Tuning Performa

Untuk menguji performa klaster MariaDB Galera di bawah tekanan tinggi, gunakan tool benchmark standar industri seperti sysbench.

Jejak perintah benchmark oltp read/write:

sysbench /usr/share/sysbench/oltp_read_write.lua \
  --mysql-host=<IP_HAPROXY> \
  --mysql-port=3306 \
  --mysql-user=bench_user \
  --mysql-password=SecurePassword \
  --mysql-db=testdb \
  --tables=10 \
  --table-size=100000 \
  --threads=64 \
  --time=60 \
  run

Metrik Kinerja Utama yang Harus Dipantau:

• wsrep_local_send_queue & wsrep_local_recv_queue: Jika nilai ini sering di atas 0.0, artinya node Anda mengalami bottleneck jaringan atau CPU, tidak mampu memproses atau mengirim write-set tepat waktu.
• wsrep_cert_failures: Angka kegagalan sertifikasi yang tinggi menandakan aplikasi backend terlalu sering melakukan modifikasi pada baris data yang sama secara konkuren. Solusinya adalah melakukan optimasi locking di level aplikasi atau mendesain ulang skema database.

10. Checklist Penerapan Produksi & Kesimpulan

Gunakan checklist berikut sebelum merilis klaster Galera MariaDB ke lingkungan production:

• Memastikan minimal 3 node aktif dengan konfigurasi IP statis.
• Sinkronisasi waktu sistem (NTP/Chrony) aktif di semua node.
• Konfigurasi innodb_autoinc_lock_mode = 2 terpasang.
• Firewall (UFW / Firewalld) membuka port 3306, 4567, 4568, dan 4444 antar node.
• Pengujian failover manual berhasil dilakukan (mematikan satu node secara mendadak dan memverifikasi kelangsungan aplikasi).
• Monitoring Prometheus dan Grafana terhubung untuk memantau metrik wsrep_* secara real-time.

Dengan mengikuti panduan komprehensif ini, Anda telah membangun fondasi arsitektur database enterprise yang tangguh, siap menghadapi lonjakan traffic ekstrem, dan menjamin ketersediaan sistem secara penuh.