Arsitektur High Availability MariaDB Galera Cluster untuk Zero Downtime

1. Konteks Industri & Analisis Akar Masalah

Dalam lanskap infrastruktur web modern, ketersediaan tinggi (High Availability / HA) bukan lagi sebuah fitur mewah, melainkan standar dasar untuk kelangsungan bisnis digital. Bayangkan sebuah platform e-commerce enterprise dengan ribuan transaksi per detik yang tiba-tiba mengalami downtime akibat kegagalan pada server database tunggal (Single Point of Failure / SPOF). Kerugian finansial, kerusakan reputasi, dan hilangnya kepercayaan pengguna adalah dampak instan yang tidak dapat ditoleransi.

Secara tradisional, arsitektur database relasional seperti MySQL atau MariaDB menggunakan model replikasi Master-Slave asinkron. Model ini memiliki kelemahan fatal: ketika Master mengalami kerusakan mendadak, terjadi replication lag yang menyebabkan hilangnya data yang belum tersinkronisasi ke Slave. Proses failover manual atau bahkan otomatis sering kali memakan waktu menit hingga jam, menghasilkan zero-uptime yang mustahil tercapai.

Sebelum penerapan MariaDB Galera Cluster, sistem umumnya bergantung pada satu node database besar dengan konfigurasi failover berbasis DNS atau Virtual IP (Keepalived). Pendekatan ini rentan terhadap split-brain syndrome, inkonsistensi data, dan pembengkakan kapasitas I/O pada satu mesin fisik.

[Sebelum: Master-Slave Tradisional (SPOF & Replication Lag)]
Client ---> [ Master DB (Write/Read) ]
                   |
                   +--- (Async Replication) ---> [ Slave DB (Read-Only) ]
                                                          (Rawan Lag & Data Hilang saat Crash)

[Sesudah: Multi-Master Galera Cluster (Sync & Zero Downtime)]
Client ---> [ ProxySQL (Load Balancer & Failover) ]
                   |
       +-----------+-----------+
       |           |           |
   [ Node 1 ] <---> [ Node 2 ] <---> [ Node 3 ]  (Certified Synchronous Replication)

Sesudah penerapan MariaDB Galera Cluster yang dikombinasikan dengan ProxySQL, arsitektur bertransformasi menjadi kluster multi-master sinkron sejati. Setiap node dapat menerima operasi read dan write secara bersamaan. Jika satu node mati secara tiba-tiba, node lainnya tetap melayani traffic tanpa kehilangan satu byte data pun, memastikan zero downtime dan konsistensi mutlak.

2. Konsep Inti & Deep Dive Arsitektur

MariaDB Galera Cluster adalah solusi penyimpanan multi-master sinkron untuk MariaDB. Inti dari teknologi ini adalah penggabungan Galera Cluster Library (sebagai plugin WSREP - Write Set Replication) dengan mesin penyimpanan InnoDB.

Alur Kerja di Balik Layar (Under the Hood)

1. Local Transaction Execution: Klien mengirimkan kueri SQL ke Node A. Transaksi dimulai secara lokal.
2. Certification Phase: Sebelum transaksi di-commit, write-set (kumpulan baris yang diubah beserta kunci primernya) dikirimkan melalui protokol multicast ke seluruh node di dalam kluster.
3. Global Ordering: Setiap node menerima write-set dan melakukan validasi konflik (certification test). Jika tidak ada konflik pada tingkat kunci baris, transaksi diberi nomor urut global (Global Sequence Number / GSN).
4. Commit & Apply: Transaksi diterapkan secara paralel di semua node. Node A mengirimkan respons sukses ke klien.

[!IMPORTANT] Galera menggunakan replikasi virtually synchronous. Artinya, secara transparan bagi pengguna, data tampak disinkronkan secara instan di semua node, meskipun secara fisik setiap node memproses antrean write-set secara independen.

+-------------------------------------------------------------+
|                  MariaDB Galera Cluster                     |
|                                                             |
|  +------------------+    WSREP API    +------------------+  |
|  |  InnoDB Storage  | <-------------> |  Galera Plugin   |  |
|  +------------------+                 +------------------+  |
|                                                ^            |
|                                                |            |
|                                           Multicast         |
|                                                v            |
|  +------------------+                 +------------------+  |
|  |  InnoDB Storage  | <-------------> |  Galera Plugin   |  |
|  +------------------+    WSREP API    +------------------+  |
+-------------------------------------------------------------+

3. Perbandingan Komparatif / Analisis Pendekatan

Untuk memahami mengapa Galera Cluster menjadi pilihan utama enterprise, mari kita bandingkan dengan pendekatan replikasi lainnya.

4. Prasyarat Sistem & Persiapan Lingkungan

Sebelum melakukan instalasi, pastikan arsitektur jaringan dan sistem operasi memenuhi spesifikasi enterprise berikut:

Topologi Lab / Produksi

• Node 1 (DB-01): 192.168.10.11 (Ubuntu Server 22.04 LTS)
• Node 2 (DB-02): 192.168.10.12 (Ubuntu Server 22.04 LTS)
• Node 3 (DB-03): 192.168.10.13 (Ubuntu Server 22.04 LTS)
• ProxySQL / Load Balancer: 192.168.10.10

Persyaratan Port Jaringan (Wajib Dibuka di Firewall/UFW)

• 3306/tcp: Port standar MariaDB (Client connection)
• 4567/tcp: Port replikasi Galera Cluster (Traffic WSREP)
• 4568/tcp: Port untuk Incremental State Transfer (IST)
• 4444/tcp: Port untuk State Snapshot Transfer (SST)

5. Panduan Implementasi Langkah demi Langkah

Langkah 1: Konfigurasi Hostname dan Resolusi DNS Lokal

Lakukan pada semua node (DB-01, DB-02, DB-03):

sudo hostnamectl set-hostname db-01
sudo tee -a /etc/hosts <<EOF
192.168.10.11 db-01
192.168.10.12 db-02
192.168.10.13 db-03
EOF

Langkah 2: Instalasi MariaDB Server & Galera 4

Tambahkan repository resmi MariaDB dan lakukan instalasi pada semua node:

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

curl -Ls 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 galera-4

Langkah 3: Konfigurasi MariaDB Galera Cluster

Hentikan layanan MariaDB terlebih dahulu di semua node:

sudo systemctl stop mariadb

Buat file konfigurasi khusus Galera di /etc/mysql/mariadb.conf.d/60-galera.cnf pada ketiga node:

[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_smm.so

# Galera Cluster Connection URL
wsrep_cluster_address="gcomm://192.168.10.11,192.168.10.12,192.168.10.13"

# Node Identification (Sesuaikan IP untuk setiap node)
wsrep_node_address="192.168.10.11"
wsrep_node_name="db-01"

# State Snapshot Transfer (SST) Configuration
wsrep_sst_method=rsync
wsrep_sst_auth="sst_user:SSTRootPassword123!"

[!NOTE] Pada db-02, ubah wsrep_node_address="192.168.10.12" dan wsrep_node_name="db-02". Pada db-03, sesuaikan dengan IP dan nama db-03.

Langkah 4: Bootstrap Cluster pada Node Pertama (db-01)

Hanya pada node pertama (db-01), inisialisasi kluster menggunakan skrip bootstrap khusus:

sudo galera_new_cluster

Verifikasi bahwa kluster telah aktif dan berjalan dengan masuk ke MariaDB:

SHOW STATUS LIKE 'wsrep_cluster_size';

Output harus menunjukkan angka 1.

Langkah 5: Bergabung ke Kluster pada Node Selanjutnya (db-02 & db-03)

Pada db-02 dan db-03, jalankan layanan MariaDB secara normal:

sudo systemctl start mariadb

Periksa kembali ukuran kluster dari salah satu node:

SHOW STATUS LIKE 'wsrep_cluster_size';

Output sekarang harus bernilai 3, menandakan ketiga node telah tergabung sempurna.

6. Bedah Kode & Penjelasan Detail Baris Kunci

Mari kita bedah parameter krusial dalam file konfigurasi /etc/mysql/mariadb.conf.d/60-galera.cnf:

• binlog_format=ROW: Galera wajib menggunakan format Row-Based Replication. Ini memastikan bahwa perubahan baris data yang spesifik dikirimkan ke seluruh node, bukan kueri SQL mentah yang dapat menghasilkan hasil berbeda akibat fungsi non-deterministik (seperti NOW() atau RAND()).
• innodb_autoinc_lock_mode=2: Mengatur mode kunci auto-increment menjadi interleaved locking. Mode ini memungkinkan pembangkitan ID auto-increment secara bersamaan di beberapa node tanpa menyebabkan table lock, krusial untuk performa multi-master write.
• wsrep_cluster_address: Menentukan alamat anggota kluster. Format gcomm:// memberitahu plugin Galera ke mana harus mencari node lain saat proses join pertama kali.
• wsrep_sst_method=rsync: Menentukan metode transfer data awal ketika node baru bergabung. rsync adalah metode cepat dan sederhana untuk dataset berukuran sedang. Untuk dataset besar (ratusan GB), gunakan xtrabackup-v2 agar tidak memblokir operasi baca/tulis selama penyalinan.

7. Skenario Produksi & Studi Kasus Dunia Nyata

Pada lingkungan produksi nyata dengan beban ribuan request web (PHP/Node.js/Go) per detik, menghubungkan aplikasi langsung secara acak ke node Galera dapat memicu deadlock transaksi (wsrep_local_cert_failures).

Solusi terbaik adalah menempatkan ProxySQL di antara aplikasi web dan kluster database.

Konfigurasi Dasar ProxySQL untuk Galera:

1. Instal ProxySQL di server terpisah (192.168.10.10).
2. Daftarkan node Galera sebagai backend server di tabel mysql_servers.
3. Konfigurasi mysql_galera_hostgroups untuk memisahkan lalu lintas Read dan Write secara otomatis.

-- Masuk ke antarmuka admin ProxySQL (port 6032, user admin:admin)
INSERT INTO mysql_servers(hostgroup_id, hostname, port) VALUES (10, '192.168.10.11', 3306);
INSERT INTO mysql_servers(hostgroup_id, hostname, port) VALUES (10, '192.168.10.12', 3306);
INSERT INTO mysql_servers(hostgroup_id, hostname, port) VALUES (10, '192.168.10.13', 3306);

-- Definisikan Galera Hostgroups
INSERT INTO mysql_galera_hostgroups(writer_hostgroup, reader_hostgroup, offline_hostgroup, active) VALUES (10, 20, 30, 1);
LOAD MYSQL SERVERS TO RUNTIME;
SAVE MYSQL SERVERS TO DISK;

Dengan konfigurasi ini, kueri INSERT, UPDATE, dan DELETE diarahkan secara cerdas ke node Writer, sementara kueri SELECT didistribusikan ke seluruh node (Reader Hostgroup) untuk skalabilitas pembacaan yang optimal.

8. Common Pitfalls, Anti-Patterns & Solusi

1. Split-Brain Syndrome pada Kluster Genap (2 Node):
   • Anti-Pattern: Membuat kluster dengan 2 node tanpa arbiter eksternal. Jika jaringan terputus antara kedua node, keduanya akan merasa dirinya yang bertahan, menyebabkan korupsi data.
   • Solusi: Selalu gunakan jumlah node ganjil (minimal 3) atau gunakan Galera Arbitrator (garbd) pada server terpisah jika anggaran terbatas.
2. Penggunaan Tabel MyISAM:
   • Anti-Pattern: Memaksa tabel dengan mesin penyimpanan MyISAM ke dalam kluster Galera.
   • Solusi: Galera hanya mendukung InnoDB. Tabel MyISAM tidak mendukung replikasi sinkron dan akan menyebabkan kegagalan replikasi atau crash pada node.
3. Ukuran Write-Set yang Terlalu Besar:
   • Anti-Pattern: Menjalankan transaksi raksasa (misal: DELETE FROM logs WHERE date < '2020-01-01') yang menghapus jutaan baris sekaligus.
   • Solusi: Pecah transaksi besar menjadi batch kecil (misal: limit 5000 baris per transaksi) untuk mencegah wsrep_max_ws_size terlampaui.

9. Benchmark, Metrik Kinerja & Tuning Performa

Untuk menguji ketahanan dan throughput kluster, gunakan benchmark tool seperti sysbench:

# Persiapan data sysbench
sysbench /usr/share/sysbench/oltp_read_write.lua \
  --mysql-host=192.168.10.10 \
  --mysql-port=6033 \
  --mysql-user=app_user \
  --mysql-password=SecurePassword \
  --mysql-db=testdb \
  --table-size=1000000 \
  prepare

# Eksekusi benchmark
sysbench /usr/share/sysbench/oltp_read_write.lua \
  --mysql-host=192.168.10.10 \
  --mysql-port=6033 \
  --mysql-user=app_user \
  --mysql-password=SecurePassword \
  --mysql-db=testdb \
  --tables=10 \
  --time=60 \
  --threads=64 \
  run

Metrik Utama yang Wajib Dipantau:

• wsrep_local_send_q & wsrep_local_recv_q: Jika nilai antrean ini sering di atas 0, berarti jaringan atau CPU mengalami bottleneck dalam memproses write-set.
• wsrep_cert_failures: Menunjukkan tingginya konflik transaksi konkuren pada baris yang sama. Jika angka ini tinggi, tinjau kembali desain aplikasi Anda.

10. Checklist Penerapan Produksi & Kesimpulan

Sebelum meluncurkan kluster MariaDB Galera ke lingkungan produksi live, pastikan Anda telah melewati checklist definitif berikut:

• Konfigurasi Firewall UFW/iptables memvalidasi port 3306, 4567, 4568, dan 4444.
• Seluruh tabel database menggunakan mesin penyimpanan InnoDB.
• Jumlah node kluster ganjil (minimal 3 node aktif) atau menggunakan Garbd untuk menghindari Split-Brain.
• ProxySQL dikonfigurasi di depan kluster untuk manajemen koneksi dan load balancing read/write.
• Pengujian Chaos Engineering (mematikan satu node secara paksa saat beban tinggi) telah berhasil dilakukan tanpa kehilangan data.
• Kebijakan backup otomatis harian dikonfigurasi menggunakan mariadb-dump atau Percona XtraBackup.

Dengan menerapkan arsitektur MariaDB Galera Cluster ini secara disiplin, infrastruktur backend Anda kini memiliki fondasi baja yang menjamin ketersediaan tinggi, konsistensi data mutlak, dan pencapaian zero downtime sejati.