Arsitektur Replikasi Multi-Master MariaDB untuk High Availability Skala Enterprise

1. Konteks Industri & Analisis Akar Masalah

Dalam lanskap arsitektur web modern skala enterprise, ketersediaan tinggi (High Availability / HA) dan skalabilitas horizontal bukan lagi sekadar fitur tambahan, melainkan prasyarat mutlak. Kegagalan infrastruktur basis data dapat melumpuhkan seluruh ekosistem digital—mulai dari sistem pemrosesan transaksi backend (PHP-FPM, Node.js, Go), pengiriman notifikasi instan via WebSocket, sinkronisasi antrean (queue) background worker dengan Supervisor, hingga layanan edge caching Cloudflare yang mengandalkan sumber data terpusat.

Secara historis, model replikasi master-slave konvensional menyisakan titik kegagalan tunggal (Single Point of Failure / SPOF) pada node Master. Ketika node Master mengalami crash atau gangguan jaringan, proses failover manual maupun otomatis sering kali memicu split-brain syndrome, inkonsistensi replikasi akibat lag, serta waktu henti (downtime) yang merugikan secara finansial.

Sebelum penerapan arsitektur multi-master terdistribusi, organisasi umumnya menghadapi masalah struktural:

• Downtime Vertikal: Pemeliharaan rutin (maintenance) atau peningkatan perangkat keras (hardware upgrade) memerlukan pemadaman layanan.
• Bottleneck Tulis (Write Bottleneck): Seluruh beban tulis terpusat pada satu instans server, membatasi kapasitas throughput sistem.
• Inkonsistensi Data: Keterlambatan replikasi asinkron menyebabkan pembacaan data basi (stale reads) pada node replica.

Setelah menerapkan arsitektur MariaDB Galera Cluster yang dikombinasikan dengan ProxySQL, organisasi memperoleh:

• Zero Single Point of Failure: Setiap node dapat bertindak sebagai pembaca sekaligus penulis (active-active multi-master).
• Sinkronisasi Ketat: Berbasis replikasi sinkron berbasis certification-based replication untuk memastikan konsistensi data absolut di seluruh node.
• Failover Transparan: Penanganan kegagalan otomatis melalui lapisan proxy cerdas tanpa memutus koneksi aplikasi klien.

2. Konsep Inti & Deep Dive Arsitektur

MariaDB Galera Cluster mengimplementasikan arsitektur multi-master active-active sejati. Berbeda dengan replikasi asinkron tradisional, Galera menggunakan protokol konsensus Virtual Synchronously dan mesin replikasi wsrep (WriteSet Replication).

Alur Kerja di Balik Layar (Under the Hood)

1. Eksekusi Transaksi Lokal: Klien mengirimkan query SQL ke salah satu node MariaDB melalui ProxySQL.
2. Persiapan WriteSet: Transaksi dieksekusi secara lokal hingga fase commit. Sebelum commit fisik ke penyimpanan, perubahan dibungkus menjadi struktur data terstandar yang disebut WriteSet.
3. Broadcast Multicast: WriteSet ini disiarkan secara asinkron/sinkron ke seluruh node lain dalam klaster menggunakan protokol komunikasi grup (Galera/gcomm).
4. Certification Test: Setiap node menerima WriteSet dan menjalankan algoritma certification secara paralel untuk mendeteksi konflik (misalnya, dua transaksi mengubah baris data yang sama secara bersamaan).
5. Apply & Commit: Jika lolos sertifikasi, WriteSet diaplikasikan ke mesin penyimpanan InnoDB pada setiap node. Jika terjadi konflik (certification failure), transaksi pada node lokal dibatalkan (rollback) secara otomatis.

+-------------------------------------------------------------+
|                        Application                          |
+-------------------------------------------------------------+
                               |
                               v
+-------------------------------------------------------------+
|                         ProxySQL                            | 
|            (Load Balancing & Query Routing)                 |+
+-------------------------------------------------------------+|
       |                       |                       |
       v                       v                       v
+--------------+        +--------------+        +--------------+
|  Node 1 (RW) | <----> |  Node 2 (RW) | <----> |  Node 3 (RW) |
| MariaDB/Galera|        | MariaDB/Galera|        | MariaDB/Galera|
+--------------+        +--------------+        +--------------+
       ^                       ^                       ^
       |-----------------------|-----------------------|
               Galera gcomm:// (WriteSet Replication)

3. Perbandingan Komparatif / Analisis Pendekatan

Berikut adalah analisis perbandingan mendalam antara tiga pendekatan arsitektur basis data skala enterprise:

*Catatan: Meskipun multi-master, penulisan konkuren pada baris tabel yang sama di node berbeda tetap dapat memicu certification conflict dan rollback.

4. Prasyarat Sistem & Persiapan Lingkungan

Untuk membangun klaster produksi yang stabil, pastikan spesifikasi infrastruktur memenuhi standar berikut:

• Infrastruktur Minimum: 3 unit Virtual Private Server (VPS) atau Bare Metal dengan sistem operasi Ubuntu 22.04 LTS.
• Koneksi Jaringan: Latensi antar node < 10ms (disarankan berada dalam satu Availability Zone atau jaringan lokal berkecepatan tinggi).
• Konfigurasi Firewall (UFW / Cloud Security Group):
  • Port 3306: Akses database standar (MariaDB).
  • Port 4567: Komunikasi replikasi Galera Cluster (TCP/UDP).
  • Port 4568: Transfer status State Snapshot Transfer (SST).
  • Port 4444: Incremental State Transfer (IST).
  • Port 6033: ProxySQL Client Traffic.

Verifikasi resolusi DNS lokal atau /etc/hosts pada ketiga node:

echo "192.168.1.101 db-node-01" | sudo tee -a /etc/hosts
echo "192.168.1.102 db-node-02" | sudo tee -a /etc/hosts
echo "192.168.1.103 db-node-03" | sudo tee -a /etc/hosts

5. Panduan Implementasi Langkah demi Langkah

Langkah 1: Instalasi MariaDB pada Semua Node

Jalankan perintah berikut pada db-node-01, db-node-02, dan db-node-03:

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

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

Buat file konfigurasi Galera pada db-node-01 (sesuaikan wsrep_node_address dan wsrep_node_name untuk node lainnya):

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

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

# Galera Cluster Connection URL
wsrep_cluster_address="gcomm://192.168.1.101,192.168.1.102,192.168.1.103"
wsrep_cluster_name="enterprise_galera_cluster"

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

# State Snapshot Transfer (SST) Configuration
wsrep_sst_method=mariabackup
wsrep_sst_auth="sst_user:SSTSecurePassword123!"

Langkah 3: Inisialisasi Klaster Pertama Kali

Hentikan layanan MariaDB di semua node:

sudo systemctl stop mariadb

Bootstrap klaster hanya pada node pertama (db-node-01):

sudo galera_new_cluster

Verifikasi bahwa node pertama telah aktif sebagai klaster tunggal:

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

Pada node kedua (db-node-02) dan ketiga (db-node-03), jalankan layanan secara normal agar mereka bergabung ke bootstrap node:

sudo systemctl start mariadb

6. Bedah Kode & Penjelasan Detail Baris Kunci

• binlog_format=ROW: Galera mewajibkan format Row-Based Replication karena perubahan baris data secara individual diperlukan untuk validasi certification.
• innodb_autoinc_lock_mode=2: Menggunakan mode interleaved locking agar pembuatan nilai AUTO_INCREMENT dapat berjalan secara paralel tanpa memblokir operasi penyisipan (insert) di node berbeda.
• wsrep_sst_method=mariabackup: Menggunakan utilitas mariabackup untuk melakukan State Snapshot Transfer secara aman dan non-blocking ketika node baru bergabung atau pulih dari kegagalan.

[!WARNING] Jangan pernah menjalankan perintah galera_new_cluster pada lebih dari satu node secara bersamaan apabila terjadi kegagalan total klaster, karena hal tersebut akan memicu split-brain dan korupsi data permanen.

7. Skenario Produksi & Studi Kasus Dunia Nyata

Dalam sistem e-commerce berskala besar dengan ribuan transaksi per detik (TPS), beban penulisan tabel inventaris dan pesanan (checkout) memerlukan isolasi tingkat tinggi. Dengan menggunakan ProxySQL di depan Galera Cluster, aplikasi PHP-FPM atau Node.js cukup melakukan koneksi ke satu port virtual ProxySQL (127.0.0.1:6033). ProxySQL secara cerdas akan mengarahkan query SELECT ke node dengan latensi terendah (read-load balancing) dan query INSERT/UPDATE/DELETE ke node aktif utama.

8. Common Pitfalls, Anti-Patterns & Solusi

1. Anti-Pattern: Tabel tanpa Primary Key
   • Masalah: Galera memerlukan Primary Key pada setiap tabel InnoDB untuk melacak perubahan baris data secara efisien. Tabel tanpa PK akan diproses sangat lambat dan memicu penurunan performa replikasi.
   • Solusi: Selalu definisikan PRIMARY KEY pada setiap pembuatan tabel skema basis data.
2. Anti-Pattern: Transaksi Terlalu Besar (Large Transactions)
   • Masalah: Transaksi yang mengubah jutaan baris dalam satu perintah SQL akan menghasilkan WriteSet berukuran masif yang melampaui batas memori buffer Galera (wsrep_max_ws_size), menyebabkan node terputus (disconnect).
   • Solusi: Pecah transaksi besar menjadi batch kecil (misalnya, batasi 5000 baris per eksekusi).

9. Benchmark, Metrik Kinerja & Tuning Performa

Untuk menguji ketahanan dan throughput klaster, gunakan utilitas sysbench:

sysbench /usr/share/sysbench/oltp_read_write.lua \
  --mysql-host=127.0.0.1 \
  --mysql-port=6033 \
  --mysql-user=sbtest \
  --mysql-password=secret \
  --mysql-db=test \
  --tables=10 \
  --table-size=100000 \
  --threads=64 \
  --time=300 \
  run

Tuning Parameter InnoDB (/etc/mysql/mariadb.conf.d/50-server.cnf):

innodb_buffer_pool_size = 70% # Sesuaikan dengan kapasitas RAM server (misal: 14G dari 20G RAM)
innodb_log_file_size = 2G
innodb_flush_log_at_trx_commit = 2
innodb_file_per_table = 1

10. Checklist Penerapan Produksi & Kesimpulan

• Seluruh node Galera menggunakan versi MariaDB yang identik.
• Konfigurasi Firewall mengizinkan port 3306, 4567, 4568, dan 4444.
• ProxySQL dikonfigurasi dengan health check aktif dan pemantauan query rules.
• Pengujian failover manual dan pemulihan node telah dilakukan di staging environment.
• Sistem pencatatan log dan monitoring (Prometheus + Grafana MariaDB Exporter) aktif memantau metrik wsrep_cluster_size dan wsrep_local_state_comment.