Arsitektur High Availability Database Cluster dengan MariaDB Galera

1. Konteks Industri & Analisis Akar Masalah

Dalam lanskap arsitektur sistem web enterprise modern, kegagalan database adalah malapetaka operasional yang dapat meruntuhkan seluruh ekosistem digital. Skenario klasik dari infrastruktur monolitik dengan satu server database utama (primary/master) dan beberapa replika baca (read-replicas) membawa Single Point of Failure (SPOF) yang masif. Ketika server utama mengalami kernel panic, korupsi penyimpanan NVMe, atau kegagalan catu daya, sistem harus melalui proses failover manual atau otomatis yang memakan waktu (Recovery Time Objective atau RTO yang tinggi), sering kali menyebabkan Downtime berjam-jam, hilangnya transaksi, dan degradasi reputasi merek yang parah.

Di tingkat backend web (baik menggunakan Node.js, Go, PHP-FPM, maupun Python), aplikasi mengandalkan konsistensi data yang ketat. Jika terjadi lag replikasi asinkron tradisional, pengguna dapat mengalami inkonsistensi data—seperti memperbarui profil namun melihat data lama pada permintaan berikutnya, atau lebih buruk lagi, konflik integritas referensial pada sistem e-commerce. Selain itu, manajemen koneksi dari connection pool seperti ProxySQL atau HAProxy sering kali mengalami timeout saat node database utama jatuh.

Sebelum penerapan MariaDB Galera Cluster, arsitektur umumnya bergantung pada Master-Slave tradisional dengan replikasi asinkron atau semisinkron. Konfigurasi ini rentan terhadap kehilangan data (data loss) jika master mati sebelum transaksi sempat dikirim ke slave. Setelah penerapan MariaDB Galera Cluster, kita beralih ke arsitektur Multi-Master Synchronous Replication, di mana setiap node dapat menerima operasi baca dan tulis secara bersamaan. Konsistensi dijamin oleh algoritma konsensus berbasis Virtual Synchrony, menghindarkan split-brain, dan memastikan RTO mendekati nol (Zero RTO) serta Recovery Point Objective (RPO) nol pada tingkat transaksi.

2. Konsep Inti & Deep Dive Arsitektur

MariaDB Galera Cluster adalah solusi penyimpanan berkecepatan tinggi yang menggabungkan mesin database InnoDB dengan Galera Cluster Library. Galera mengimplementasikan replikasi multi-master berbasis sertifikasi (certification-based replication). Berbeda dengan replikasi tradisional berbasis statement atau row yang dikirimkan secara sekuensial setelah eksekusi, Galera mereplikasi writeset (kumpulan baris yang diubah beserta hash transaksi) secara paralel sebelum transaksi tersebut di-commit secara lokal.

Berikut adalah diagram alur eksekusi transaksi (Write Path) di dalam Galera Cluster:

+------------------+
| Client / Backend |
+--------+---------+
         |
         | 1. SQL Query (INSERT/UPDATE)
         v
+--------+---------+        2. Broadcast Writeset
|  Node 1 (Local)  +------------------------------------+
+--------+---------+                                    |
         |                                              v
         | 3. Certification Test                 +------+---------+
         | (Conflict Check)                      |  Node 2 (Peer) |
         v                                       +----------------+
+--------+---------+
| Apply & Commit   |
+------------------+

Alur Detail di Balik Layar:

1. Klien mengirimkan transaksi ke Node 1. Transaksi dieksekusi secara lokal di dalam ruang memori InnoDB buffer pool tanpa melakukan commit akhir.
2. Generasi Writeset: Saat pernyataan COMMIT dikeluarkan, Galera membungkus perubahan baris menjadi sebuah writeset yang berisi ID transaksi, kunci baris yang diubah, dan payload data.
3. Broadcasting (GCS Engine): Writeset ini disiarkan ke seluruh node lain di dalam klaster menggunakan Galera Communication Engine (GCS) yang menerapkan protokol urutan total (total order multicast).
4. Certification: Setiap node menerima writeset secara bersamaan dalam urutan yang sama persis. Setiap node melakukan tes sertifikasi secara independen untuk memeriksa apakah ada konflik kunci baris dengan transaksi lain yang sedang berjalan.
5. Commit / Rollback: Jika tes sertifikasi lolos, transaksi di-commit secara permanen ke penyimpanan disk lokal. Jika terjadi konflik (dua transaksi mengubah baris yang sama secara bersamaan), transaksi dengan urutan lebih lambat akan digugurkan (rolled back) dan mengembalikan error Deadlock found when trying to get lock kepada aplikasi.

3. Perbandingan Komparatif / Analisis Pendekatan

Tabel berikut membandingkan tiga pendekatan arsitektur replikasi database utama dalam ekosistem enterprise:

[!WARNING] Jangan pernah menerapkan Galera Cluster dengan jumlah node genap (misal 2 node) tanpa tambahan Arbitrator (garbd). Kehilangan satu node pada klaster 2-node akan memecah kuorum dan membuat seluruh klaster read-only atau menolak koneksi sama sekali akibat risiko split-brain.

4. Prasyarat Sistem & Persiapan Lingkungan

Untuk membangun klaster produksi yang stabil, pastikan spesifikasi infrastruktur dan prasyarat jaringan terpenuhi:

Spesifikasi Lingkungan

• OS: Ubuntu 22.04 LTS / Debian 12 / RHEL 9 (Gunakan kernel Linux terbaru).
• Topologi: 3 Node Virtual Private Server (VPS) atau Bare Metal dengan IP lokal privat.
  • node1: 10.0.1.11
  • node2: 10.0.1.12
  • node3: 10.0.1.13
• Jaringan: Latensi antar node < 5ms, Bandwidth minimal 1Gbps, port firewall yang harus dibuka: 3306 (MySQL), 4567 (Galera Cluster replication traffic), 4568 (Incremental State Transfer), 4444 (State Snapshot Transfer).

Persiapan Sistem Operasi (Jalankan di Semua Node)

# Perbarui sistem
sudo apt update && sudo apt upgrade -y

# Atur hostname yang sesuai
sudo hostnamectl set-hostname db-node1

# Konfigurasi /etc/hosts untuk resolusi nama internal
echo "10.0.1.11 db-node1" | sudo tee -a /etc/hosts
echo "10.0.1.12 db-node2" | sudo tee -a /etc/hosts
echo "10.0.1.13 db-node3" | sudo tee -a /etc/hosts

5. Panduan Implementasi Langkah demi Langkah

Langkah 1: Instalasi MariaDB Server & Galera Cluster

Lakukan instalasi MariaDB versi terbaru (MariaDB 10.11 LTS atau 11.4 LTS) di semua node:

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

Langkah 2: Konfigurasi Firewall (UFW)

sudo ufw allow 22/tcp
sudo ufw allow 3306/tcp
sudo ufw allow 4567/tcp
sudo ufw allow 4568/tcp
sudo ufw allow 4444/tcp
sudo ufw enable

Langkah 3: Konfigurasi MariaDB Galera (server.cnf)

Buat file konfigurasi khusus Galera di setiap node pada direktori /etc/mysql/mariadb.conf.d/65-galera.cnf.

Contoh konfigurasi untuk db-node1 (10.0.1.11):

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

# Galera Cluster Connection URL
wsrep_cluster_address="gcomm://10.0.1.11,10.0.1.12,10.0.1.13"

# Node Identification
wsrep_node_address="10.0.1.11"
wsrep_node_name="db-node1"

# SST (State Snapshot Transfer) Method
wsrep_sst_method=rsync

# InnoDB Optimizations for Galera
innodb_flush_log_at_trx_commit=2
innodb_buffer_pool_size=2G

[!TIP] Sesuaikan wsrep_node_address dan wsrep_node_name pada db-node2 (10.0.1.12) dan db-node3 (10.0.1.13) sesuai dengan IP dan nama host masing-masing.

Langkah 4: Inisialisasi Klaster Pertama Kali

Matikan layanan MariaDB di semua node terlebih dahulu:

sudo systemctl stop mariadb

Inisialisasi bootstrap hanya pada node pertama (db-node1):

sudo galera_new_cluster

Verifikasi bahwa node pertama telah menjadi bootstrap primer:

SHOW STATUS LIKE 'wsrep_cluster_size';
-- Output harus bernilai 1

Di node kedua (db-node2) dan ketiga (db-node3), jalankan layanan MariaDB secara normal:

sudo systemctl start mariadb

Periksa kembali ukuran klaster dari salah satu node:

SHOW STATUS LIKE 'wsrep_cluster_size';
-- Output harus bernilai 3

6. Bedah Kode & Penjelasan Detail Baris Kunci

Mari kita bedah parameter krusial dalam file konfigurasi 65-galera.cnf di atas:

• binlog_format=ROW: Sangat Wajib. Galera membutuhkan format Row-Based Replication untuk melacak perubahan tingkat baris secara presisi guna mendeteksi konflik sertifikasi.
• innodb_autoinc_lock_mode=2: Mengatur mode kunci auto-increment ke interleaved locking. Mode ini menghilangkan penguncian tabel saat melakukan operasi INSERT massal, memungkinkan penulisan paralel dari beberapa node tanpa saling memblokir.
• wsrep_cluster_address: Menyatakan daftar alamat IP semua node dalam bentuk string koneksi gcomm://. Saat node bergabung, ia akan mencoba menghubungi IP yang tertera dalam daftar untuk melakukan State Transfer (IST atau SST).
• wsrep_sst_method=rsync: Menentukan metode transfer status saat node baru bergabung atau ketinggalan jauh. rsync adalah metode bawaan yang cepat untuk skala kecil-menengah. Untuk produksi skala besar, disarankan menggunakan mariabackup agar tidak mengunci tabel saat penyalinan data berlangsung.
• innodb_flush_log_at_trx_commit=2: Meningkatkan performa tulis (I/O throughput) dengan cara menulis log transaksi ke memori setiap detik, alih-alih melakukan sync ke disk pada setiap transaksi commit. Meskipun ada risiko kehilangan data beberapa detik jika server mengalami hard power loss, hal ini sangat direkomendasikan pada Galera untuk mengurangi latensi replikasi jaringan.

7. Skenario Produksi & Studi Kasus Dunia Nyata

Studi Kasus: High-Traffic E-Commerce Flash Sale

Sebuah platform e-commerce menghadapi lonjakan 50.000 permintaan per detik saat Flash Sale. Arsitektur backend menggunakan Go (Golang) dengan framework Fiber dan connection pool terdistribusi yang terhubung ke ProxySQL di hadapan 3 node MariaDB Galera Cluster.

Konfigurasi ProxySQL untuk Load Balancing & Failover

ProxySQL bertindak sebagai lapisan perantara (middleware) yang mendistribusikan query tulis (INSERT/UPDATE/DELETE) ke semua node Galera secara round-robin atau berdasarkan bobot, serta mengarahkan query baca (SELECT) dengan efisien.

-- Masuk ke antarmuka admin ProxySQL (mysql -u admin -padmin -h 127.0.0.1 -P 6032)

-- Tambahkan server ke hostgroup tulis (misal: Hostgroup 10)
INSERT INTO mysql_servers (hostgroup_id, hostname, port) VALUES (10, '10.0.1.11', 3306);
INSERT INTO mysql_servers (hostgroup_id, hostname, port) VALUES (10, '10.0.1.12', 3306);
INSERT INTO mysql_servers (hostgroup_id, hostname, port) VALUES (10, '10.0.1.13', 3306);

-- Konfigurasi aturan query untuk mengarahkan transaksi ke hostgroup
INSERT INTO mysql_query_rules (rule_id, active, match_pattern, destination_hostgroup, apply)
VALUES (1, 1, '^SELECT.*FOR UPDATE', 10, 1);

LOAD MYSQL SERVERS TO RUNTIME;
SAVE MYSQL SERVERS TO DISK;

Ketika db-node1 mengalami kegagalan hardware mendadak, ProxySQL secara otomatis mendeteksi kegagalan kesehatan (health check) dalam kurun waktu kurang dari 1 detik dan mengalihkan seluruh traffic tulis ke db-node2 dan db-node3 tanpa ada error yang sampai ke aplikasi backend Go.

8. Common Pitfalls, Anti-Patterns & Solusi

1. Anti-Pattern: Menjalankan Transaksi Berukuran Masif (Large Transactions)

   • Masalah: Menjalankan DELETE FROM logs WHERE date < '2023-01-01' yang memuat jutaan baris dalam satu transaksi tunggal akan menghasilkan writeset berukuran besar yang melebihi batas wsrep_max_ws_size (default 2GB atau batas RAM), menyebabkan node mengalami abort dan keluar dari klaster.
   • Solusi: Lakukan pemecahan batching (chunking).

     -- Lakukan penghapusan secara bertahap
     WHILE (SELECT ROW_COUNT() > 0) DO
       DELETE FROM logs WHERE date < '2023-01-01' LIMIT 5000;
       SELECT SLEEP(0.1);
     END WHILE;
     

2. Pitfall: Mengabaikan Pemantauan Status Kuorum (wsrep_cluster_status)

   • Masalah: Administrator sering kali berasumsi klaster aman selama layanan mariadb aktif, padahal node bisa saja terisolasi dari kuorum (Non-Operational state).
   • Solusi: Selalu buat pemantauan otomatis (Prometheus + Grafana / Node Exporter) yang memeriksa metrik:

     SHOW STATUS LIKE 'wsrep_local_state_comment'; -- Harus bernilai 'Synced'
     SHOW STATUS LIKE 'wsrep_cluster_status';      -- Harus bernilai 'Primary'
     

9. Benchmark, Metrik Kinerja & Tuning Performa

Untuk menguji ketahanan dan throughput klaster MariaDB Galera, gunakan alat benchmarking seperti sysbench:

# Menyiapkan data benchmark sysbench
sysbench /usr/share/sysbench/oltp_read_write.lua \
  --mysql-host=127.0.0.1 \
  --mysql-port=3306 \
  --mysql-user=root \
  --mysql-password=secret \
  --mysql-db=test \
  --tables=10 \
  --table-size=100000 prepare

# Menjalankan pengujian beban konkurensi tinggi
sysbench /usr/share/sysbench/oltp_read_write.lua \
  --mysql-host=127.0.0.1 \
  --mysql-port=3306 \
  --mysql-user=root \
  --mysql-password=secret \
  --mysql-db=test \
  --tables=10 \
  --table-size=100000 \
  --threads=64 \
  --time=60 \
  --report-interval=10 run

Interpretasi Metrik Kinerja Utama:

• Transactions Per Second (TPS): Pada jaringan lokal 1Gbps dengan NVMe, klaster 3-node yang sehat umumnya dapat mempertahankan 3.000 - 8.000 TPS tergantung pada kompleksitas indeks.
• wsrep_cert_deps_distance: Menunjukkan seberapa banyak transaksi paralel yang dapat diproses tanpa konflik. Nilai yang tinggi (>50) menunjukkan paralelisme yang baik.
• wsrep_local_bf_aborts (Brute Force Aborts): Jika angka ini melonjak drastis, artinya aplikasi Anda sering mengalami deadlock tingkat tinggi akibat banyak node menulis ke tabel yang sama secara simultan. Solusinya adalah mendesain ulang skema tabel atau memisahkan domain penulisan (sharding logic di tingkat aplikasi).

10. Checklist Penerapan Produksi & Kesimpulan

Sebelum meluncurkan klaster MariaDB Galera ke lingkungan produksi (live environment), pastikan Anda telah menyelesaikan checklist verifikasi berikut:

• Jumlah node dalam klaster ganjil (Minimal 3 node, atau 2 node + 1 Arbitrator garbd).
• Konfigurasi binlog_format=ROW dan innodb_autoinc_lock_mode=2 aktif di semua node.
• Port jaringan (3306, 4567, 4568, 4444) terbuka di firewall dan diuji menggunakan nc atau telnet.
• Metode SST menggunakan mariabackup untuk menghindari penguncian tabel yang lama pada basis data berukuran besar.
• Penggunaan Connection Pooler (seperti ProxySQL atau HAProxy) diterapkan di sisi aplikasi untuk menangani failover transparan.
• Sistem pemantauan (Monitoring) berbasis Prometheus dan Grafana terkonfigurasi untuk memantau metrik wsrep_cluster_size dan wsrep_local_state_comment.

Dengan menerapkan arsitektur MariaDB Galera Cluster secara disiplin sesuai panduan mendalam ini, sistem backend web enterprise Anda kini memiliki fondasi data yang sangat tangguh, berdaya tahan tinggi terhadap kegagalan perangkat keras, serta siap menghadapi lonjakan traffic ekstrem tanpa mengorbankan konsistensi integritas data.