High-Performance MariaDB Clustering & Replication untuk Skala Enterprise

1. Konteks Industri & Analisis Akar Masalah

Dalam lanskap arsitektur web modern yang menuntut ketersediaan tinggi (high availability) dan latensi rendah, kegagalan database tunggal (single point of failure atau SPOF) bukanlah sebuah pilihan. Ketika sebuah platform enterprise mengalami lonjakan traffic—baik dari aplikasi berbasis PHP-FPM, Node.js, Go, maupun arsitektur microservices—beban pada lapisan penyimpanan data meningkat secara eksponensial. Pendekatan tradisional menggunakan Master-Slave asynchronous replication sering kali gagal memenuhi ekspektasi modern karena masalah replication lag, hilangnya data saat failover mendadak, serta kebutuhan intervensi manual yang kompleks.

Bottleneck performa tidak hanya terletak pada perangkat keras, tetapi juga pada bagaimana manajemen konkurensi, penguncian baris (row-level locking), dan alokasi memori dikonfigurasikan. Sebelum penerapan cluster berbasis Galera, infrastruktur enterprise sering kali menderita inkonsistensi data ketika node primer mendadak down, proses failover memakan waktu hingga puluhan menit, dan lonjakan query menyebabkan koneksi database jenuh (connection pool exhaustion).

Setelah penerapan High-Performance MariaDB Clustering menggunakan Galera dengan optimasi Buffer Pool yang tepat, arsitektur bertransformasi menjadi sistem multi-master synchronous replication. Setiap node dapat menerima operasi tulis (write) dan baca (read), menghilangkan bottleneck latensi replikasi, dan menjamin zero data loss (RPO = 0) serta near-zero downtime (RTO mendekati nol).

2. Konsep Inti & Deep Dive Arsitektur

Galera Cluster adalah solusi replikasi multi-master sinkronis berbasis pustaka sertifikasi group communication (Galera Cluster 4). Di balik layar, Galera menggabungkan beberapa komponen kunci: teknologi replikasi berbasis Write-Set, mekanisme konsensus virtual synchronous, dan protokol kontrol aliran (flow control).

Berikut adalah alur eksekusi transaksi di dalam Galera Cluster:

[ Aplikasi / Web Server ]
         │
         ▼
┌─────────────────┐       Sertifikasi       ┌─────────────────┐
│     Node 1      │ ─────────────────────►  │     Node 2      │
│  (Local Write)  │                         │ (Cert. Check)   │
└─────────────────┘                         └─────────────────┘
         │                                           │
         └─────────────────┬─────────────────────────┘
                           │
                           ▼
                   [ Galera Provider ]
                   (WSREP / gcomm://)
                           │
                           ▼
┌─────────────────────────────────────────────────────────────┐
│                     Virtual Synchrony                       │
│         (Semua node menerima write-set secara bersamaan)    │
└─────────────────────────────────────────────────────────────┘

Ketika sebuah transaksi dieksekusi pada Node 1, perubahan tidak langsung ditulis ke disk permanen secara terisolasi. MariaDB menghasilkan Write-Set (kumpulan baris yang diubah beserta kunci primernya) yang kemudian dikirim melalui lapisan komunikasi grup (gcomm) ke semua node lain di dalam cluster. Sebelum commit disetujui, setiap node melakukan pemeriksaan sertifikasi (certification test) secara independen. Jika tidak ada konflik pada kunci primer dengan transaksi lain yang berjalan bersamaan, transaksi diterima dan diterapkan secara paralel di semua node.

3. Perbandingan Komparatif / Analisis Pendekatan

Untuk memahami mengapa Galera Cluster menjadi standar emas enterprise, mari kita bandingkan dengan pendekatan replikasi lainnya:

[!WARNING] Jangan pernah menjalankan Galera Cluster dengan jumlah node genap (misal: 2 node) tanpa instance Arbitrator (garbd). Cluster membutuhkan kuorum (majority > 50%) untuk mencegah split-brain syndrome. Konfigurasi minimal produksi yang disarankan adalah 3 node penuh.

4. Prasyarat Sistem & Persiapan Lingkungan

Sebelum melakukan instalasi MariaDB Galera Cluster, pastikan lingkungan infrastruktur memenuhi spesifikasi berikut:

• OS: Ubuntu 22.04 LTS / RHEL 9 (Clean installation)
• Hardware Minimum (per node): 4 vCPU, 8 GB RAM, NVMe Storage
• Jaringan: IP Lokal privat dengan latensi < 10ms antar node
• Port Firewall yang Harus Dibuka:
  • 3306/tcp: Port standar MariaDB untuk klien dan aplikasi
  • 4567/tcp: Port replikasi Galera Cluster (gcomm)
  • 4568/tcp: Port transfer state incremental (IST)
  • 4444/tcp: Port transfer state donor / snapshot (DST)

Lakukan verifikasi hostname dan konfigurasi /etc/hosts di setiap node agar dapat saling mengenali via hostname privat:

# /etc/hosts pada setiap node
10.0.1.101 node1
10.0.1.102 node2
10.0.1.103 node3

5. Panduan Implementasi Langkah demi Langkah

Langkah 1: Instalasi MariaDB dan Galera Provider

Jalankan perintah berikut pada ketiga node:

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

# Tambahkan repository resmi MariaDB 10.11 LTS
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 2: Konfigurasi MariaDB Server & Galera (Node 1)

Hentikan layanan MariaDB terlebih dahulu, lalu buat file konfigurasi khusus Galera di /etc/mysql/mariadb.conf.d/99-galera.cnf:

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

# Galera Cluster Configuration
wsrep_on=ON
wsrep_provider=/usr/lib/galera/libgalera_sstr.so
wsrep_cluster_name="enterprise_galera_cluster"
wsrep_cluster_address="gcomm://10.0.1.101,10.0.1.102,10.0.1.103"

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

# SST Configuration
wsrep_sst_method=mariabackup
wsrep_sst_auth="galera_sst:SuperSecurePassword123!"

# Performance Tuning untuk Buffer Pool
innodb_buffer_pool_size=4G
innodb_log_file_size=1G
innodb_flush_log_at_trx_commit=2
innodb_file_per_table=1

Langkah 3: Konfigurasi User SST untuk MariaDB Backup

Masuk ke konsol MariaDB pada Node 1 untuk membuat pengguna khusus State Snapshot Transfer (SST):

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

Langkah 4: Bootstrapping Cluster

Bootstrapping hanya dilakukan sekali pada node pertama (node1):

sudo systemctl stop mariadb
sudo galera_new_cluster

Periksa status cluster dengan masuk ke MariaDB:

SHOW STATUS LIKE 'wsrep_cluster_size';

Hasil harus menunjukkan angka 1.

Langkah 5: Bergabung ke Cluster (Node 2 dan Node 3)

Pada node2 dan node3, salin file konfigurasi /etc/mysql/mariadb.conf.d/99-galera.cnf (sesuaikan wsrep_node_address dan wsrep_node_name), lalu jalankan layanan secara normal:

sudo systemctl start mariadb

Verifikasi kembali ukuran cluster dari node manapun:

SHOW STATUS LIKE 'wsrep_%';

Pastikan wsrep_cluster_size bernilai 3 dan wsrep_ready bernilai ON.

6. Bedah Kode & Penjelasan Detail Baris Kunci

Mari kita bedah parameter krusial dalam file konfigurasi 99-galera.cnf:

1. binlog_format=ROW: Galera wajib menggunakan format Row-Based Replication. Statement-based replication tidak akan bekerja karena Galera perlu melacak perubahan tingkat baris persis untuk validasi sertifikasi.
2. innodb_autoinc_lock_mode=2: Mengatur mode kunci auto-increment menjadi interleaved locking. Ini krusial agar beberapa node dapat menghasilkan kunci auto-increment secara bersamaan tanpa menyebabkan bottleneck antrean tabel.
3. wsrep_cluster_address="gcomm://...": Menentukan daftar bootstrapping awal. Format URL gcomm:// memberitahu node tempat mencari anggota cluster lain saat pertama kali dihidupkan.
4. innodb_flush_log_at_trx_commit=2: Mengurangi frekuensi penulisan log transaksi ke disk fisik secara langsung pada setiap commit (menulis ke cache OS setiap detik). Ini mendongkrak performa tulis secara drastis, dengan risiko kehilangan data maksimal 1 detik jika terjadi kernel panic (meskipun diatasi oleh redundansi cluster).

7. Skenario Produksi & Studi Kasus Dunia Nyata

Pada sistem e-commerce berskala besar dengan beban transaksi ribuan checkout per detik, arsitektur aplikasi (misalnya backend Go atau PHP-FPM) dihubungkan menggunakan ProxySQL atau HAProxy di depan Galera Cluster.

[ Aplikasi (Go / PHP) ]
         │
         ▼
    [ HAProxy ]
   ┌─────┴─────┐
   ▼           ▼
[Node 1]    [Node 2]    (Write / Read Load Balanced)
   │           │
   └─────┬─────┘
         ▼
     [Node 3]

Konfigurasi HAProxy untuk load balancing SQL:

global
    log /dev/log local0
    maxconn 4096

defaults
    log global
    option tcplog
    option dontlognull
    retries 3
    timeout queue 1m
    timeout connect 10s
    timeout client 30m
    timeout server 30m

frontend mariadb_front
    bind 10.0.1.200:3306
    mode tcp
    default_backend mariadb_back

backend mariadb_back
    mode tcp
    balance roundrobin
    option tcp-check
    server node1 10.0.1.101:3306 check inter 2s rise 2 fall 3
    server node2 10.0.1.102:3306 check inter 2s rise 2 fall 3
    server node3 10.0.1.103:3306 check inter 2s rise 2 fall 3

[!TIP] Gunakan ProxySQL alih-alih HAProxy mentah jika Anda membutuhkan query routing tingkat lanjut (misal: read-splitting untuk mengarahkan query SELECT berat ke node tertentu dan INSERT/UPDATE ke node utama).

8. Common Pitfalls, Anti-Patterns & Solusi

• Anti-Pattern 1: Menjalankan Transaksi Berukuran Raksasa (Mega-Transactions). Dampak: Transaksi yang mengubah jutaan baris sekaligus dalam satu query akan membanjiri write-set buffer, menyebabkan Node Desync atau bahkan Cluster Deadlock. Solusi: Pecah transaksi besar menjadi batch kecil (misal: LIMIT 5000 per eksekusi loop).
• Anti-Pattern 2: Menggunakan Tabel Non-InnoDB (MyISAM). Dampak: Galera tidak mendukung replikasi tabel non-transaksional. Penggunaan MyISAM akan memicu error WSREP: non-InnoDB table. Solusi: Pastikan semua tabel dikonversi ke InnoDB dengan perintah ALTER TABLE table_name ENGINE=InnoDB;.
• Pitfall 3: Mengabaikan Pengaturan wsrep_load_data_splitting. Solusi: Hindari perintah LOAD DATA INFILE masif tanpa batching karena dapat memicu flow control pause yang menghentikan seluruh cluster.

9. Benchmark, Metrik Kinerja & Tuning Performa

Pengujian performa dapat dilakukan menggunakan tool sysbench untuk mensimulasikan beban OLTP secara masif:

# Inisialisasi database sysbench
sysbench /usr/share/sysbench/oltp_read_write.lua \
  --mysql-host=10.0.1.200 \
  --mysql-user=root \
  --mysql-password=secret \
  --mysql-db=test \
  --table-size=1000000 \
  prepare

# Menjalankan benchmark konkurensi tinggi
sysbench /usr/share/sysbench/oltp_read_write.lua \
  --mysql-host=10.0.1.200 \
  --mysql-user=root \
  --mysql-password=secret \
  --mysql-db=test \
  --table-size=1000000 \
  --threads=64 \
  --time=300 \
  run

Parameter tuning lanjutan yang wajib disesuaikan di 99-galera.cnf berdasarkan hasil benchmark:

# Ukuran Cache Write-Set untuk mencegah jeda flow control
wsrep_provider_options="gcache.size=2G; gmcast.segment=0"

# Optimasi Thread Pool untuk konkurensi tinggi
thread_handling=pool-of-threads
thread_pool_size=8

10. Checklist Penerapan Produksi & Kesimpulan

Sebelum merilis cluster MariaDB Galera ke lingkungan produksi live, pastikan checklist berikut terpenuhi:

• Konfigurasi minimal 3 node aktif atau menggunakan Arbitrator.
• Format biner log diatur ke ROW.
• Parameter innodb_buffer_pool_size diatur 70-80% dari total RAM sistem.
• Mekanisme backup otomatis menggunakan mariadb-backup terjadwal via Cron.
• Monitoring kesehatan node terintegrasi dengan Prometheus dan Grafana (menggunakan mysqld_exporter).
• Pengujian simulasi pemutusan kabel jaringan (network partition / split-brain test) sudah dilakukan di staging.

Dengan mengikuti arsitektur dan konfigurasi di atas, infrastruktur database enterprise Anda kini memiliki fondasi yang tangguh, tahan banting, konsisten secara sinkronis, dan siap melayani skala traffic jutaan pengguna tanpa hambatan.