High Availability MariaDB Cluster dengan Galera dan ProxySQL

1. Konteks Industri & Analisis Akar Masalah

Dalam lanskap infrastruktur web modern, arsitektur aplikasi berbasis monolith tradisional atau microservices yang bergantung pada satu buah server database relasional (Single Point of Failure / SPOF) sudah lama ditinggalkan oleh perusahaan-perusahaan teknologi tingkat enterprise. Ketika aplikasi web mengalami lonjakan trafik, kegagalan pada lapisan database tidak hanya mengakibatkan downtime layanan, tetapi juga kerugian finansial yang masif serta rusaknya reputasi brand. Masalah klasik yang sering dihadapi oleh Database Administrators (DBA) dan Backend Architects meliputi:

1. Single Point of Failure (SPOF): Jika node database utama (primary) mati, seluruh operasi tulis (write) terhenti total sampai intervensi manual dilakukan.
2. Keterbatasan Skalabilitas Tulis: Arsitektur Master-Slave tradisional sering kali membebankan seluruh operasi tulis ke satu master, sementara replikasi asinkron atau semi-sinkron rentan terhadap replication lag dan kehilangan data (data loss) saat terjadi failover mendadak.
3. Lonjakan Koneksi (Connection Storm): Aplikasi web modern dengan ratusan worker PHP-FPM, Node.js, atau Go secara bersamaan membuka ribuan koneksi persisten ke database, yang langsung melampaui batas maksimal threads_connected pada MariaDB, berujung pada Out of Memory (OOM) atau penolakan koneksi baru (Too many connections).

Sebelum penerapan arsitektur High Availability berbasis Galera Cluster dan ProxySQL, infrastruktur biasanya mengandalkan satu server database dengan skema cold standby atau replikasi manual yang rentan human error. Sesudah penerapan arsitektur multi-master sinkronus dengan load balancing dan connection pooling cerdas melalui ProxySQL, sistem mampu menoleransi matinya salah satu node tanpa kehilangan data sepeser pun, mendistribusikan beban secara optimal, dan mengamankan aplikasi dari connection starvation.

2. Konsep Inti & Deep Dive Arsitektur

Galera Cluster adalah solusi multi-master database cluster sinkronus untuk MariaDB yang dibangun di atas teknologi * certificación-based replication* dan pustaka Group Communication Framework (Galera wsrep). Berbeda dengan replikasi tradisional MySQL yang bersifat asinkron, Galera menjamin bahwa transaksi diterapkan secara konsisten di semua node secara paralel (certification-based), menghilangkan risiko split-brain jika dikonfigurasikan dengan jumlah node minimal yang ganjil (biasanya 3 node).

ProxySQL bertindak sebagai lapisan perantara (middleware) berperforma tinggi yang cerdas (smart proxy). Ia memisahkan trafik Read dan Write, melakukan query caching, serta memelihara connection pool sehingga aplikasi tidak pernah langsung menghantam engine database secara membabi buta.

+-------------------------------------------------------------+
|                    Client Applications                      |
|         (PHP-FPM, Node.js, Go Backend, Python Workers)      |
+------------------------------id-----------------------------+
                               |
                               v (Port 6033)
+-------------------------------------------------------------+
|                        ProxySQL                             |
|        - Query Rules (Read/Write Splitting)                 |
|        - Connection Pooling & Multiplexing                  |
+-------+-----------------------------+-----------------------+
        |                             |                       |
        v                             v                       v
+---------------+             +---------------+       +---------------+
| MariaDB Node 1| <=========> | MariaDB Node 2| <===> | MariaDB Node 3|
|  (Galera WSREP|             |  (Galera WSREP|       |  (Galera WSREP|
|   Multi-Master|             |   Multi-Master|       |   Multi-Master|
+---------------+             +---------------+       +---------------+

Alur data berjalan sebagai berikut: Aplikasi mengirimkan query ke ProxySQL. ProxySQL menganalisis query tersebut menggunakan tabel aturan (query rules). Jika query berupa INSERT, UPDATE, atau DELETE, ProxySQL merutekannya ke hostgroup penulisan (writer). Jika query berupa SELECT, ProxySQL mendistribusikannya ke hostgroup pembacaan (readers) menggunakan algoritma weighted round-robin. Di lapisan bawah, MariaDB Galera Cluster memastikan setiap transaksi tulis disinkronkan ke seluruh node sebelum transaksi tersebut dianggap sukses secara penuh (commit).

3. Perbandingan Komparatif / Analisis Pendekatan

[!WARNING] Jangan pernah menggunakan jumlah node genap (misal 2 node) pada Galera Cluster tanpa arbitrator (garbd), karena akan memicu skenario split-brain ketika terjadi gangguan jaringan (network partition).

4. Prasyarat Sistem & Persiapan Lingkungan

Untuk membangun arsitektur production-grade ini, persiapkan 4 unit Virtual Private Server (VPS) atau Bare Metal dengan sistem operasi Ubuntu 22.04 LTS atau Debian 12, dengan spesifikasi minimal:

• Node 1 (MariaDB DB01): 4 vCPU, 8 GB RAM, 100 GB NVMe (IP: 192.168.1.11)
• Node 2 (MariaDB DB02): 4 vCPU, 8 GB RAM, 100 GB NVMe (IP: 192.168.1.12)
• Node 3 (MariaDB DB03): 4 vCPU, 8 GB RAM, 100 GB NVMe (IP: 192.168.1.13)
• Node 4 (ProxySQL & App Gateway): 2 vCPU, 4 GB RAM, 50 GB NVMe (IP: 192.168.1.20)

Pastikan koneksi jaringan lokal (private network) antar node memiliki latensi di bawah 2 milidetik (< 2ms) dan nonaktifkan swap pada seluruh node Linux untuk menjamin performa mesin virtual Java/InnoDB:

sudo swapoff -a
sudo sed -i '/swap/d' /etc/fstab

Atur resolusi hostname pada /etc/hosts di semua node agar saling mengenali:

192.168.1.11 db01
192.168.1.12 db02
192.168.1.13 db03
192.168.1.20 proxy01

5. Panduan Implementasi Langkah demi Langkah

Langkah 1: Instalasi MariaDB & Galera Cluster (Pada Node 1, 2, dan 3)

Tambahkan repository resmi MariaDB 10.11 LTS pada ketiga node database:

sudo apt update && sudo apt install -y curl software-properties-common gnupg
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

Hentikan layanan MariaDB sebelum melakukan konfigurasi cluster:

sudo systemctl stop mariadb

Langkah 2: Konfigurasi Galera pada Node 1 (/etc/mysql/mariadb.conf.d/65-galera.cnf)

Buat file konfigurasi Galera pada Node 1 dengan isi persis seperti 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_smm.so

# Galera Cluster Connection URL
wsrep_cluster_address="gcomm://192.168.1.11,192.168.1.12,192.168.1.13"

# Cluster Name
wsrep_cluster_name="enterprise_galera_cluster"

# Node Specific Configuration (Ubah IP sesuai node masing-masing)
wsrep_node_address="192.168.1.11"
wsrep_node_name="db01"

# State Transfer Configuration
wsrep_sst_method=mariabackup
wsrep_sst_auth="sstuser:SuperSecretSSTPassword123!"

[!NOTE] Salin file konfigurasi di atas ke Node 2 dan Node 3, namun sesuaikan nilai wsrep_node_address dan wsrep_node_name sesuai identitas masing-masing node (192.168.1.12 untuk db02, dan 192.168.1.13 untuk db03).

Langkah 3: Inisialisasi Bootstrap Cluster Pertama kali (Hanya di Node 1)

Jalankan perintah khusus bootstrap eksklusif pada Node 1:

sudo galera_new_cluster

Verifikasi bahwa node telah aktif sebagai primary component dengan masuk ke MySQL:

SHOW STATUS LIKE 'wsrep_cluster_size';

Output harus menunjukkan angka 1. Selanjutnya, buat user SST (State Snapshot Transfer) pada Node 1 agar node lain dapat bergabung:

CREATE USER 'sstuser'@'localhost' IDENTIFIED BY 'SuperSecretSSTPassword123!';
GRANT RELOAD, LOCK TABLES, REPLICATION CLIENT ON *.* TO 'sstuser'@'localhost';
FLUSH PRIVILEGES;

Langkah 4: Bergabung dengan Cluster (Di Node 2 dan Node 3)

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

sudo systemctl start mariadb

Periksa kembali ukuran cluster dari salah satu node:

SHOW STATUS LIKE 'wsrep_cluster_size';

Jika konfigurasi benar, output sekarang akan menunjukkan angka 3.

Langkah 5: Instalasi & Konfigurasi ProxySQL (Pada Node 4)

Install ProxySQL dari repository resmi:

sudo apt update
wget https://github.com/sysown/proxysql/releases/download/v2.5.5/proxysql_2.5.5-ubuntu22_amd64.deb
sudo dpkg -i proxysql_2.5.5-ubuntu22_amd64.deb
sudo systemctl enable --now proxysql

Masuk ke console admin ProxySQL (Default user: admin, password: admin, port: 6032):

mysql -u admin -padmin -h 127.0.0.1 -P 6032

Jalankan skrip SQL berikut untuk mendaftarkan node MariaDB ke ProxySQL:

-- Masukkan server backend Galera ke mysql_servers
INSERT INTO mysql_servers(hostgroup_id, hostname, port) VALUES (10, '192.168.1.11', 3306);
INSERT INTO mysql_servers(hostgroup_id, hostname, port) VALUES (10, '192.168.1.12', 3306);
INSERT INTO mysql_servers(hostgroup_id, hostname, port) VALUES (10, '192.168.1.13', 3306);

-- Definisikan hostgroup 10 sebagai writer sekaligus reader dalam model Galera
INSERT INTO mysql_replication_hostgroups(writer_hostgroup, reader_hostgroup, comment) VALUES (10, 10, 'Galera Multi-Master');

-- Tambahkan user database aplikasi
INSERT INTO mysql_users(username, password, default_hostgroup) VALUES ('app_user', '*9F765...hashedpassword...', 10);

-- Simpan konfigurasi ke memori runtime dan disk
LOAD MYSQL SERVERS TO RUNTIME;
SAVE MYSQL SERVERS TO DISK;
LOAD MYSQL USERS TO RUNTIME;
SAVE MYSQL USERS TO DISK;

6. Bedah Kode & Penjelasan Detail Baris Kunci

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

• binlog_format=ROW: Galera mewajibkan format binary log berbasis baris (row-based replication). Tanpa parameter ini, replikasi mutasi data berbasis pernyataan (statement-based) akan gagal menyinkronkan data non-deterministik seperti fungsi NOW() atau UUID() di seluruh node.
• innodb_autoinc_lock_mode=2: Mengatur mode penguncian auto-increment menjadi interleaved lock mode. Ini sangat vital dalam cluster multi-master agar setiap node dapat menghasilkan nilai ID auto-increment secara bersamaan tanpa saling menunggu (lock contention), menghindari duplikasi kunci primer (primary key collision).
• wsrep_sst_method=mariabackup: Menentukan metode transfer data awal saat node baru bergabung atau pulih dari kegagalan. mariabackup adalah metode modern yang aman, non-blocking, dan tidak mengunci tabel saat proses snapshot berlangsung, jauh lebih unggul dibanding metode usang seperti rsync atau mysqldump.

7. Skenario Produksi & Studi Kasus Dunia Nyata

Bayangkan sebuah platform e-commerce dengan trafik flash sale mencapai 50.000 request per detik. Jika menggunakan satu server database, lonjakan koneksi dari aplikasi Node.js akan langsung melumpuhkan sistem.

Dengan arsitektur Galera + ProxySQL:-

1. Aplikasi backend mengirimkan koneksi database ke IP ProxySQL (192.168.1.20:6033).
2. ProxySQL melakukan multiplexing, menampung ribuan koneksi dari aplikasi, namun hanya mempertahankan beberapa koneksi fisik persisten yang stabil ke ketiga node MariaDB.
3. Jika Node 1 (192.168.1.11) mengalami kerusakan hardware mendadak, ProxySQL secara otomatis mendeteksi kegagalan melalui pemeriksaan kesehatan berkala (health check), mengeluarkan Node 1 dari rotasi hostgroup, dan mengalihkan seluruh trafik secara instan ke Node 2 dan Node 3 tanpa satu pun error yang sampai ke layar pengguna akhir (zero downtime failover).

8. Common Pitfalls, Anti-Patterns & Solusi

• Anti-Pattern 1: Menggunakan tabel berjenis MyISAM. Solusi: Galera hanya mendukung penuh mesin penyimpanan transaksi InnoDB. Penggunaan MyISAM akan menyebabkan error konsistensi dan menghentikan replikasi wsrep.
• Anti-Pattern 2: Melakukan operasi DDL besar (ALTER TABLE) tanpa perlindungan. Solusi: Operasi DDL di Galera bersifat Total Order Isolation (TOI) yang mengunci seluruh node cluster selama eksekusi. Gunakan teknik Rolling Schema Upgrade atau tool pihak ketiga seperti gh-ost untuk tabel berukuran raksasa.
• Pitfall 3: Mengabaikan pemantauan antrean wsrep (wsrep_flow_control_paused). Solusi: Jika node terlambat memproses transaksi, Galera akan menjeda aliran data (flow control). Pantau metrik ini secara berkala; jika nilainya di atas 0.05, artinya kapasitas node sudah jenuh dan membutuhkan penambahan sumber daya CPU atau optimasi kueri lambat (slow queries).

9. Benchmark, Metrik Kinerja & Tuning Performa

Pengujian performa dapat dilakukan menggunakan tool standar industri seperti sysbench untuk mensimulasikan beban OLTP (Online Transaction Processing) secara masif pada ProxySQL:

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

# Jalankan benchmark beban tinggi
sysbench /usr/share/sysbench/oltp_read_write.lua \
  --mysql-host=192.168.1.20 \
  --mysql-port=6033 \
  --mysql-user=app_user \
  --mysql-password=SecurePassword \
  --mysql-db=testdb \
  --threads=64 \
  --time=300 \
  --report-interval=10 run

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

innodb_buffer_pool_size = 5G  # Alokasikan 70-80% RAM tersedia pada node
innodb_log_file_size = 1G
innodb_flush_log_at_trx_commit = 2  # Meningkatkan performa tulis dengan risiko minimal
max_connections = 2000

10. Checklist Penerapan Produksi & Kesimpulan

Sebelum meluncurkan arsitektur ini ke lingkungan produksi live, pastikan seluruh item dalam checklist berikut telah terpenuhi:

• Jumlah node MariaDB ganjil (minimal 3 node) untuk menghindari split-brain.
• Latensi jaringan antar node database stabil di bawah 2ms.
• Firewall (UFW / iptables) mengizinkan port internal Galera (3306, 4567, 4568, 4444) hanya antar IP cluster.
• ProxySQL dikonfigurasi dengan connection pooling dan mekanisme health check aktif.
• Skema backup otomatis menggunakan mariabackup dan penyimpanan terpusat (S3/MinIO) sudah terjadwal di cron.
• Sistem monitoring (Prometheus + Grafana + MariaDB Exporter) terpasang untuk memantau metrik wsrep_cluster_size dan wsrep_local_state_comment.

Dengan menerapkan panduan komprehensif ini, Anda telah membangun fondasi infrastruktur database enterprise yang tangguh, sangat tersedia (highly available), dan siap menghadapi eskalasi bisnis masa depan.