High Availability MariaDB Galera Cluster dengan ProxySQL untuk High Concurrency

1. Konteks Industri & Analisis Akar Masalah

Dalam lanskap arsitektur web modern, skalabilitas dan high availability (HA) untuk lapisan database adalah fondasi mutlak yang tidak boleh ditawar. Ketika sebuah sistem backend—baik dibangun menggunakan Node.js, Go, PHP-FPM, maupun arsitektur microservices—menghadapi lonjakan transaksi bersamaan (high concurrency), model tradisional primary-replica (master-slave tunggal) sering kali menemui hambatan fatal. Bottleneck utama muncul pada titik kegagalan tunggal (single point of failure atau SPOF) di server primary, latensi replikasi asinkron yang memicu read-after-write inconsistency, serta keterbatasan kapasitas tulis (write scaling) yang hanya bertumpu pada satu node.

Secara historis, administrator sistem mengandalkan replikasi master-slave dengan failover otomatis menggunakan alat eksternal seperti Orchestrator atau MHA (Master High Availability). Namun, pendekatan ini memiliki celah risiko berupa split-brain syndrome dan jeda waktu (downtime) selama proses promosi replica menjadi master baru. Dampaknya fatal bagi aplikasi finansial, e-commerce, atau platform SaaS enterprise yang menuntut zero data loss dan uptime 99.999%.

Sebelum penerapan klaster Galera yang dipadukan dengan ProxySQL:

• Kondisi Eksisting: Aplikasi mengirimkan seluruh kueri baca (SELECT) dan tulis (INSERT/UPDATE/DELETE) langsung ke satu instance MariaDB utama. Ketika traffic melonjak, CPU utilization pada primary node melompat ke 100%, memicu connection pool exhaustion, dan seluruh layanan web mendadak tidak responsif.
• Kondisi Sesudah Penerapan: Dengan mengimplementasikan MariaDB Galera Cluster, kita mendistribusikan operasi tulis ke beberapa node multi-master secara sinkron menggunakan sertifikasi berbasis write-set. Dipadukan dengan ProxySQL di hadapannya, seluruh kueri secara cerdas di-routing: kueri tulis dilempar ke node master Galera, sementara kueri baca didistribusikan secara merata (load balancing) ke seluruh node, secara drastis mengeliminasi bottleneck dan mendongkrak kapasitas konkuren hingga ratusan ribu request per detik.

2. Konsep Inti & Deep Dive Arsitektur

MariaDB Galera Cluster adalah solusi penyimpanan multi-master sinkron untuk sistem manajemen basis data relasional. Berbeda dengan replikasi tradisional MySQL yang bersifat asinkron atau semi-sinkron, Galera menggunakan arsitektur replikasi berbasis certification-based replication yang dikombinasikan dengan komunikasi kelompok virtual (Virtual Synchronous Group Communication).

Alur Kerja di Balik Layar (Under the Hood)

1. Eksekusi Transaksi Lokal: Klien mengirimkan query transaksi ke Node A (misalnya melalui ProxySQL).
2. Persiapan Write-Set: Transaksi dieksekusi secara lokal pada Node A. Ketika perintah COMMIT dipanggil, sebelum data ditulis secara permanen ke penyimpanan disk lokal, Node A mengekstrak perubahan data ke dalam struktur biner yang disebut Write-Set.
3. Replikasi Multicast: Node A menyiarkan (broadcast) Write-Set tersebut ke seluruh node lain di dalam klaster (Node B dan Node C) menggunakan protokol komunikasi grup WSREP (Write-Set Replication).
4. Sertifikasi (Certification): Setiap node menerima Write-Set dan melakukan pemeriksaan independen (certification test) untuk mendeteksi apakah ada konflik dengan transaksi lain yang sedang berjalan secara konkuren. Jika terjadi konflik (misalnya dua transaksi mengubah baris tabel yang sama secara bersamaan), transaksi dengan urutan sertifikasi yang kalah akan digugurkan (rolled back).
5. Komitmen Global: Jika lolos sertifikasi, setiap node menerapkan Write-Set ke mesin penyimpanan InnoDB mereka masing-masing secara bersamaan. Transaksi dinyatakan selesai (committed) secara global di seluruh klaster.

+-----------------------------------------------------------------------+
|                           Aplikasi Backend                            |
+-----------------------------------------------------------------------+
                                    |
                                    v
+-----------------------------------------------------------------------+
|                    ProxySQL (Query Routing & LB)                      |
+-----------------------------------------------------------------------+
           |                                         |
           | (Write Queries: INSERT/UPDATE/DELETE)   | (Read Queries: SELECT)
           v                                         v
+-----------------------+                 +-----------------------------+
|   MariaDB Node 1      |<===============>|      MariaDB Node 2         |
|   (Galera Master)     |  WSREP Sync     |      (Galera Replica)       |
+-----------------------+  Replication    +-----------------------------+
           ^                                         ^
           |                                         |
           +=========================================+
                         MariaDB Node 3
                         (Galera Replica)

3. Perbandingan Komparatif / Analisis Pendekatan

Untuk memahami mengapa kombinasi Galera Cluster dan ProxySQL merupakan standar industri terbaik, mari kita bandingkan dengan dua arsitektur alternatif:

[!WARNING]
Jangan pernah menggunakan jumlah node genap (misal 2 atau 4 node) dalam Galera Cluster. Klaster wajib menggunakan jumlah ganjil (minimal 3 node) untuk menghindari split-brain saat terjadi partisi jaringan (network partition), di mana mekanisme quorum memerlukan suara mayoritas agar klaster tetap dapat beroperasi.

4. Prasyarat Sistem & Persiapan Lingkungan

Sebelum memulai instalasi, pastikan Anda menyiapkan 3 unit server (bisa berupa VPS atau Bare Metal) yang berada dalam satu jaringan lokal (LAN) dengan latensi minimal (< 2ms) untuk memastikan performa replikasi WSREP optimal.

Spesifikasi Minimum Environment:

• OS: Ubuntu 22.04 LTS / Debian 12 / AlmaLinux 9
• RAM: Minimal 4 GB per node (disarankan 8 GB+ untuk produksi)
• CPU: Minimal 2 vCPU per node
• Software: MariaDB Server 10.11+ dan ProxySQL 2.5+

Konfigurasi Hostname & IP (Contoh Simulasi):

• db-node-01: 192.168.1.101
• db-node-02: 192.168.1.102
• db-node-03: 192.168.1.103
• proxysql-node: 192.168.1.200

Pastikan /etc/hosts di setiap node dikonfigurasi dengan benar agar komunikasi antar node menggunakan nama host.

cat <<EOF | sudo tee -a /etc/hosts
192.168.1.101 db-node-01
192.168.1.102 db-node-02
192.168.1.103 db-node-03
192.168.1.200 proxysql-node
EOF

5. Panduan Implementasi Langkah demi Langkah

Langkah 1: Instalasi MariaDB dan Galera di Ketiga Node

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

sudo apt update
sudo apt install -y curl rsync ufw

# Tambahkan repository resmi MariaDB
curl -sS 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 MariaDB Galera pada Node Pertama (db-node-01)

Hentikan layanan MariaDB terlebih dahulu:

sudo systemctl stop mariadb

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

[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 Cluster Address
wsrep_cluster_address="gcomm://192.168.1.101,192.168.1.102,192.168.1.103"

# Cluster Name
wsrep_cluster_name="galera_production_cluster"

# Node Specific Configuration
wsrep_node_address="192.168.1.101"
wsrep_node_name="db-node-01"

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

Salin file konfigurasi ini ke db-node-02 dan db-node-03, namun sesuaikan parameter wsrep_node_address dan wsrep_node_name sesuai dengan IP dan hostname masing-masing node.

Langkah 3: Inisialisasi Klaster Pertama Kali

Hanya pada db-node-01, jalankan perintah bootstrap untuk membuat klaster baru:

sudo mariadb_secure_installation
sudo galera_new_cluster

Verifikasi bahwa klaster telah aktif dengan masuk ke MariaDB dan mengecek status Galera:

SHOW STATUS LIKE 'wsrep_cluster_size';

Output harus menunjukkan angka 1.

Langkah 4: Bergabung dengan Node Kedua dan Ketiga

Pada db-node-02 dan db-node-03, jalankan layanan MariaDB secara normal (tanpa bootstrap):

sudo systemctl start mariadb

Kembali ke db-node-01, jalankan kembali perintah SHOW STATUS LIKE 'wsrep_cluster_size';. Nilainya kini harus berubah menjadi 3, menandakan ketiga node telah bergabung dalam satu kesatuan sinkron.

Langkah 5: Instalasi dan Konfigurasi ProxySQL

Pindah ke server proxysql-node (192.168.1.200):

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 start proxysql
sudo systemctl enable proxysql

Akses antarmuka administrasi ProxySQL via port 6032 (default user: admin, password: admin):

mariadb -u admin -padmin -h 127.0.0.1 -P6032

Masukkan konfigurasi server backend MariaDB ke dalam ProxySQL:

-- Masukkan node MariaDB ke dalam connection pool (Hostgroup 10 = Writers, Hostgroup 20 = Readers)
INSERT INTO mysql_servers(hostgroup_id, hostname, port) VALUES (10, '192.168.1.101', 3306);
INSERT INTO mysql_servers(hostgroup_id, hostname, port) VALUES (20, '192.168.1.101', 3306);
INSERT INTO mysql_servers(hostgroup_id, hostname, port) VALUES (20, '192.168.1.102', 3306);
INSERT INTO mysql_servers(hostgroup_id, hostname, port) VALUES (20, '192.168.1.103', 3306);

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

Konfigurasikan pengguna database dan aturan perutean query (query rules):

-- Tambahkan kredensial pengguna database aplikasi
INSERT INTO mysql_users(username, password, default_hostgroup) VALUES ('app_user', PASSWORD('AppSecretPassword!'), 10);
LOAD MYSQL USERS TO RUNTIME;
SAVE MYSQL USERS TO DISK;

-- Aturan Query: Arahkan SELECT non-FOR UPDATE ke Hostgroup 20 (Readers)
INSERT INTO mysql_query_rules (rule_id, active, match_pattern, destination_hostgroup, apply) 
VALUES (1, 1, '^SELECT.*', 20, 1);

-- Aturan Query: Arahkan transaksi tulis ke Hostgroup 10 (Writer)
INSERT INTO mysql_query_rules (rule_id, active, match_pattern, destination_hostgroup, apply) 
VALUES (2, 1, '^(INSERT|UPDATE|DELETE|REPLACE).*', 10, 1);

LOAD MYSQL QUERY RULES TO RUNTIME;
SAVE MYSQL QUERY RULES TO DISK;

[!TIP]
ProxySQL mendengarkan koneksi aplikasi pada port 6033. Ubah konfigurasi string koneksi aplikasi backend Anda (PHP, Node.js, Go) agar mengarah ke 192.168.1.200:6033 alih-alih langsung ke IP database individual.

6. Bedah Kode & Penjelasan Detail Baris Kunci

Mari kita bedah beberapa parameter kritis dalam konfigurasi 60-galera.cnf yang menentukan stabilitas klaster:

• binlog_format=ROW: Galera mewajibkan format Row-Based Replication (RBR). Format Statement-Based akan menyebabkan inkonsistensi data karena perintah seperti UUID() atau fungsi waktu dieksekusi secara berbeda di setiap node.
• innodb_autoinc_lock_mode=2: Mengaktifkan interleaved lock mode. Dalam lingkungan multi-master, kunci tabel tradisional untuk auto-increment (MODE 0 atau 1) akan memicu bottleneck parah karena serialisasi operasi tulis. Mode 2 mengizinkan beberapa node menghasilkan nilai auto-increment secara bersamaan tanpa mengunci tabel secara global.
• wsrep_sst_method=rsync: Menentukan metode State Snapshot Transfer. Ketika node baru bergabung atau pulih dari kegagalan total, rsync digunakan untuk menyalin seluruh direktori data dari node donor. Untuk database berukuran ratusan gigabyte, metode ini dapat digantikan dengan xtrabackup-v2 agar transfer data dilakukan secara online tanpa mengunci tabel secara fisik terlalu lama.

7. Skenario Produksi & Studi Kasus Dunia Nyata

Bayangkan sebuah platform e-commerce flash sale yang menangani 50.000 transaksi checkout per detik. Jika menggunakan arsitektur tunggal, database akan langsung kolaps.

Dengan arsitektur ProxySQL + Galera Cluster:

1. Lonjakan koneksi HTTP diterima oleh Nginx, diteruskan ke backend Go/Node.js.
2. Backend membuka koneksi secara masif ke ProxySQL pada port 6033.
3. ProxySQL melakukan connection pooling, menampung puluhan ribu koneksi aplikasi secara efisien tanpa membebani proses daemon MariaDB secara langsung.
4. Kueri pembacaan katalog produk (SELECT) disebar secara merata melalui round-robin ke db-node-01, db-node-02, dan db-node-03.
5. Kueri transaksi pembelian stok produk (UPDATE inventory) diarahkan secara eksklusif ke node writer utama. Jika node tersebut mengalami gangguan mendadak, ProxySQL secara otomatis mendeteksi kegagalan kesehatan (health check) dan mengalihkan lalu lintas tulis ke node Galera aktif lainnya dalam hitungan milidetik tanpa intervensi manual.

8. Common Pitfalls, Anti-Patterns & Solusi

1. Anti-Pattern: Menulis ke Berbagai Node Secara Agresif Tanpa Manajemen Konflik

   • Masalah: Meskipun Galera adalah multi-master, jika aplikasi menulis ke baris tabel yang sama di node berbeda secara bersamaan, certification failure akan terjadi, memicu rollback transaksi dan error Deadlock found when trying to get lock pada aplikasi.
   • Solusi: Rancang arsitektur aplikasi agar melakukan sharding logis atau pastikan operasi tulis untuk entitas tertentu selalu diarahkan ke node writer yang sama melalui ProxySQL sticky connections.

2. Pitfalls: Melakukan Restart Klaster dengan Urutan yang Salah Saat Terjadi Power Failure Total

   • Masalah: Jika seluruh server mati bersamaan, menjalankan perintah systemctl start mariadb secara acak akan membuat node menolak bergabung karena perbedaan GTID / seqno (sequence number).
   • Solusi: Cek file /var/lib/db-node-XX/grastate.dat pada setiap node. Cari node yang memiliki seqno paling tinggi (paling mutakhir), lalu jalankan perintah bootstrap galera_new_cluster hanya pada node tersebut. Pada node lainnya, cukup jalankan systemctl start mariadb biasa.

9. Benchmark, Metrik Kinerja & Tuning Performa

Untuk menguji ketahanan klaster, gunakan alat benchmark industri seperti sysbench:

-- Buat database benchmark di dalam klaster via ProxySQL
CREATE DATABASE sbtest;

# Inisialisasi tabel sysbench
sysbench /usr/share/sysbench/oltp_read_write.lua \
  --mysql-host=192.168.1.200 \
  --mysql-port=6033 \
  --mysql-user=app_user \
  --mysql-password=AppSecretPassword! \
  --mysql-db=sbtest \
  --tables=10 \
  --table-size=100000 \
  prepare

# Jalankan benchmark konkurensi tinggi
sysbench /usr/share/sysbench/oltp_read_write.lua \
  --mysql-host=192.168.1.200 \
  --mysql-port=6033 \
  --mysql-user=app_user \
  --mysql-password=AppSecretPassword! \
  --mysql-db=sbtest \
  --tables=10 \
  --table-size=100000 \
  --threads=250 \
  --time=60 \
  run

Parameter Tuning Lanjutan di my.cnf:

[mysqld]
innodb_buffer_pool_size = 70% # Alokasikan 70-80% total RAM server untuk InnoDB Buffer Pool
innodb_log_file_size = 2G
innodb_flush_log_at_trx_commit = 2 # Meningkatkan performa tulis secara drastis (risiko kehilangan data 1 detik terakhir jika server crash total)
max_connections = 2000

10. Checklist Penerapan Produksi & Kesimpulan

• Pastikan jumlah node Galera ganjil (3 atau 5 node) untuk mencegah split-brain.
• Konfigurasi firewall (ufw) untuk membuka port Galera (3306, 4567, 4568, 4444) hanya antar IP internal klaster.
• Pastikan ProxySQL dikonfigurasi dengan pemeriksaan kesehatan (health check interval) yang agresif (misal setiap 1000ms).
• Uji skenario failover secara berkala di lingkungan staging sebelum rilis ke produksi.
• Jadwalkan backup rutin menggunakan mariabackup secara terpusat.

Dengan memadukan MariaDB Galera Cluster dan ProxySQL, Anda telah membangun arsitektur database kelas enterprise yang tangguh, siap menelan lonjakan beban high concurrency, serta memberikan jaminan ketersediaan layanan tanpa kompromi.