MariaDB Galera Cluster Tuning untuk High Availability

1. Konteks Industri & Analisis Akar Masalah

Dalam lanskap arsitektur web modern yang menuntut ketersediaan layanan 99.999% (five-nines availability), kegagalan database (single point of failure atau SPOF) adalah bencana operasional yang tidak dapat ditoleransi. Beban aplikasi dari backend berbasis PHP/Go/Node.js, integrasi dengan antrean pesan (message queue seperti RabbitMQ/Redis), hingga layanan real-time WebSocket sangat bergantung pada stabilitas subsistem penyimpanan data relasional.

Secara historis, replikasi master-slave tradisional pada MySQL atau MariaDB sering kali mengalami masalah serius seperti replication lag, inkonsistensi data saat terjadi failover mendadak, dan risiko split-brain jika manajemen peralihan master dilakukan secara manual atau otomatis tanpa kuorum yang ketat. Ketika lonjakan traffic terjadi akibat kampanye pemasaran atau serangan mendadak, arsitektur master-slave konvensional akan kewalahan karena operasi tulis (write operations) terpusat pada satu node tunggal.

MariaDB Galera Cluster hadir sebagai solusi Multi-Master High Availability Synchronous Replication berbasis sertifikasi. Dengan Galera, setiap node di dalam kluster dapat menerima operasi baca dan tulis secara bersamaan (active-active). Namun, tanpa pemahaman mendalam mengenai parameter tuning jaringan, konfigurasi State Snapshot Transfer (SST), optimasi InnoDB Buffer Pool, dan mitigasi split-brain, kluster Galera di lingkungan produksi justru rentan mengalami penurunan performa drastis akibat write-set replication latency dan certification failures.

Sebelum vs Sesudah Implementasi Galera Cluster

2. Konsep Inti & Deep Dive Arsitektur

MariaDB Galera Cluster mengintegrasikan mesin database MariaDB dengan Galera Cluster Plugin (menggunakan antarmuka WSREP atau WriteSet Replication). Berbeda dengan replikasi asinkron tradisional, Galera menggunakan model replikasi sinkron berbasis kelompok (virtually synchronous replication).

Alur Kerja di Balik Layar (Under the Hood)

1. Eksekusi Transaksi Lokal: Klien mengirimkan kueri SQL (misal: UPDATE, INSERT) ke Node A. Transaksi dieksekusi secara lokal di dalam InnoDB dengan status optimistic locking.
2. Generasi Write-Set: Ketika transaksi mencapai tahap COMMIT, mesin wsrep mengekstrak perubahan baris data (write-set), mengenkripsinya (opsional), dan menyiarkannya ke seluruh node lain di dalam kluster melalui protokol komunikasi grup (Galera/GMM).
3. Sertifikasi (Certification Test): Setiap node yang menerima write-set melakukan uji sertifikasi secara independen di memori. Node memeriksa apakah ada konflik dengan transaksi lain yang sedang berjalan secara bersamaan. Jika tidak ada konflik, transaksi disetujui.
4. Commit & Delivery: Node menerapkan write-set ke penyimpanan lokal masing-masing. Jika terjadi konflik pada suatu node, transaksi pada node tersebut dibatalkan (rolled back) untuk menjaga konsistensi mutlak.

[ Client Application ]
         │
         ▼ (SQL Query: INSERT/UPDATE)
┌────────────────────────────────────────┐
│               Node A                   │
│  ┌──────────────────────────────────┐  │
│  │ Local Execution (InnoDB Engine)  │  │
│  └────────────────┬─────────────────┘  │
│                   ▼                    │
│  ┌──────────────────────────────────┐  │
│  │ Generate & Broadcast Write-Set   │──┼──────────────┐
│  └──────────────────────────────────┘  │              │
└────────────────────────────────────────┘              ▼
                   │                     ┌──────────────────────────────┐
                   │ (Multicast/Unicast) │           Node B             │
                   └────────────────────►│ 1. Receive Write-Set         │
                                         │ 2. Certification Test        │
                                         │ 3. Apply to Local Storage    │
                                         └──────────────────────────────┘

3. Perbandingan Komparatif / Analisis Pendekatan

Dalam membangun infrastruktur penyimpanan data yang resilien, arsitek sering kali dihadapkan pada beberapa pilihan teknologi replikasi. Berikut adalah analisis komparatif mendalam antara Galera Cluster, MySQL Group Replication (MGR), dan Arsitektur Tradisional Master-Slave dengan ProxySQL.

[!WARNING] Jangan pernah menggunakan Galera Cluster di atas jaringan WAN dengan latensi tinggi (> 100ms antar node) karena mekanisme penguncian dan sertifikasi sinkron akan menyebabkan deadlock masif, flow control terpicu, dan performa throughput turun drastis hingga mendekati nol.

4. Prasyarat Sistem & Persiapan Lingkungan

Sebelum melakukan instalasi MariaDB Galera Cluster, pastikan lingkungan infrastruktur memenuhi spesifikasi teknis minimum dan konfigurasi jaringan berikut:

Spesifikasi Minimum Hardware (Per Node)

• CPU: 4 vCPU / Core (Direkomendasikan 8+ core untuk beban tinggi).
• RAM: 8 GB (Alokasikan 70-80% untuk InnoDB Buffer Pool).
• Network: Minimal 1 Gbps terdedikasi dengan latensi antar node < 5ms.
• Storage: NVMe SSD dengan performa IOPS tinggi untuk menghindari hambatan fsync.

Persiapan Jaringan & Firewall

Pastikan port-port berikut terbuka di seluruh node kluster (menggunakan ufw atau firewalld):

• 3306/tcp: Port standar MariaDB untuk klien dan aplikasi.
• 4567/tcp: Port untuk komunikasi replikasi Galera Cluster (Multicast/Unicast).
• 4568/tcp: Port untuk transfer Incremental State Transfer (IST).
• 4444/tcp: Port untuk transfer State Snapshot Transfer (SST) melalui rsync/mariabackup.

# Konfigurasi UFW pada Ubuntu/Debian
sudo ufw allow 3306/tcp
sudo ufw allow 4567/tcp
sudo ufw allow 4568/tcp
sudo ufw allow 4444/tcp
sudo ufw reload

5. Panduan Implementasi Langkah demi Langkah

Ikuti langkah-langkah di bawah ini untuk membangun kluster 3-node MariaDB Galera di atas sistem operasi Ubuntu 22.04 LTS.

Langkah 1: Instalasi MariaDB Server

Lakukan pada semua node (Node 1, Node 2, dan Node 3):

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

# Tambahkan repository resmi MariaDB 10.11 LTS
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 rsync

Langkah 2: Konfigurasi Galera Cluster di MariaDB

Hentikan layanan MariaDB terlebih dahulu pada semua node:

sudo systemctl stop mariadb

Buat file konfigurasi khusus Galera di /etc/mysql/mariadb.conf.d/65-galera.cnf. Masukkan konfigurasi lengkap berikut (sesuaikan alamat IP node Anda):

[mysqld]
# Pengaturan Engine & Karakter
default-storage-engine      = InnoDB
innodb_file_per_table       = 1
innodb_autoinc_lock_mode    = 2

# Pengaturan Jaringan & Koneksi
bind-address                = 0.0.0.0
max_connections             = 1000

# Konfigurasi Galera WSREP Provider
wsrep_on                    = ON
wsrep_provider              = /usr/lib/galera/libgalera_sstr.so

# Alamat Kluster (Ganti dengan IP internal masing-masing node)
wsrep_cluster_address       = "gcomm://192.168.1.10,192.168.1.11,192.168.1.12"

# Nama Kluster
wsrep_cluster_name          = "production-galera-cluster"

# Identitas Node (Ganti IP sesuai node tempat file ini berada)
wsrep_node_address          = "192.168.1.10"
wsrep_node_name             = "db-node-01"

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

[galera]
# Opsional tambahan parameter replikasi

Langkah 3: Membuat Pengguna SST

Pada node pertama (db-node-01), jalankan MariaDB secara bootstrap untuk inisialisasi kluster pertama kali:

sudo galera_new_cluster

Masuk ke konsol MySQL/MariaDB:

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

Langkah 4: Menjalankan Node Pendukung (Node 2 & Node 3)

Pada node kedua (db-node-02) dan ketiga (db-node-03), pastikan file konfigurasi /etc/mysql/mariadb.conf.d/65-galera.cnf sudah disesuaikan wsrep_node_address dan wsrep_node_name-nya, lalu jalankan layanan secara normal:

sudo systemctl start mariadb

Verifikasi status kluster dengan masuk ke MariaDB dan jalankan kueri berikut:

SHOW STATUS LIKE 'wsrep_cluster_size';
SHOW STATUS LIKE 'wsrep_connected';
SHOW STATUS LIKE 'wsrep_ready';

Jika wsrep_cluster_size bernilai 3 dan wsrep_ready bernilai ON, kluster Galera Anda telah berhasil diinisialisasi.

6. Bedah Kode & Penjelasan Detail Baris Kunci

Mari kita bedah parameter krusial dalam file konfigurasi 65-galera.cnf yang menentukan stabilitas dan performa sistem:

• innodb_autoinc_lock_mode = 2 (Interleaved lock mode): Parameter ini wajib diset ke 2 di Galera Cluster. Mode tradisional (0 atau 1) menggunakan table-level locks saat operasi INSERT dengan AUTO_INCREMENT, yang akan memicu konflik masif dan menghentikan replikasi multi-master secara sinkron. Mode 2 aman karena menggunakan alokasi ID yang aman untuk replikasi paralel.
• wsrep_provider: Menunjuk langsung ke pustaka inti Galera (libgalera_sstr.so). Pustaka inilah yang memproses komunikasi antar node, manajemen keanggotaan kluster, dan algoritma sertifikasi transaksi.
• wsrep_sst_method = mariabackup: Metode transfer rekam jepret (State Snapshot Transfer) menggunakan mariabackup jauh lebih unggul dibandingkan metode lama seperti rsync atau mysqldump. mariabackup melakukan streaming data biner secara aman tanpa mengunci tabel secara penuh (non-blocking backup), sangat krusial untuk database berukuran ratusan gigabyte.

7. Skenario Produksi & Studi Kasus Dunia Nyata

Kasus: E-Commerce Skala Besar Menghadapi Flash Sale

Sebuah platform e-commerce dengan backend Node.js dan ribuan worker queue memproses 5.000 transaksi per detik selama flash sale.

Strategi Arsitektur:

1. Pemisahan Beban (Read/Write Splitting): Aplikasi menggunakan ProxySQL di depan 3 node Galera Cluster. Seluruh kueri baca (SELECT) didistribusikan secara load-balancing ke semua node. Kueri tulis (INSERT/UPDATE) diarahkan ke Node 1 secara default, namun secara otomatis dialihkan ke node lain jika Node 1 mengalami failover.
2. Tuning Flow Control: Untuk mencegah satu node yang lambat memperlambat seluruh kluster, parameter wsrep_cert_deps_distance dan wsrep_slave_threads disesuaikan agar replikasi berjalan secara multi-threaded.

# Tambahan tuning untuk multi-threaded slave replication
wsrep_slave_threads = 8
innodb_thread_concurrency = 0
innodb_read_io_threads = 8
innodb_write_io_threads = 8

8. Common Pitfalls, Anti-Patterns & Solusi

1. Anti-Pattern: Menggunakan Tabel Non-Transactional (MyISAM)

   • Masalah: Galera hanya mendukung mesin penyimpanan transaksional seperti InnoDB. Penggunaan tabel MyISAM akan menyebabkan kegagalan replikasi (replication failure) atau data tidak disinkronkan ke node lain.
   • Solusi: Konversikan seluruh tabel ke InnoDB menggunakan perintah ALTER TABLE table_name ENGINE=InnoDB; dan tambahkan sql_mode = STRICT_TRANS_TABLES.

2. Pitfalls: Mematikan Node Secara Bersamaan (Graceful Shutdown Failure)

   • Masalah: Mematikan seluruh node kluster secara paksa (hard reset/power off) menyebabkan hilangnya informasi urutan status kluster (bootstrap state), sehingga saat dinyalakan kembali kluster mengalami split-brain atau gagal mendeteksi node utama.
   • Solusi: Selalu matikan layanan secara berurutan atau pastikan node terakhir yang dimatikan menjadi node pertama yang di-bootstrap ulang dengan galera_new_cluster.

9. Benchmark, Metrik Kinerja & Tuning Performa

Untuk memastikan kluster mampu menangani beban produksi, lakukan pengujian beban menggunakan perangkat sysbench:

# Inisialisasi data test sysbench
sysbench /usr/share/sysbench/oltp_read_write.lua \
  --mysql-host=192.168.1.10 \
  --mysql-user=root \
  --mysql-password=Password123! \
  --mysql-db=test \
  --table-size=1000000 \
  --tables=10 prepare

# Jalankan benchmark oltp read-write
sysbench /usr/share/sysbench/oltp_read_write.lua \
  --mysql-host=192.168.1.10 \
  --mysql-user=root \
  --mysql-password=Password123! \
  --mysql-db=test \
  --tables=10 \
  --time=300 \
  --threads=64 run

Metrik Kunci untuk Dimonitor (Prometheus & Grafana)

• wsrep_local_send_q & wsrep_local_recv_q: Jika nilai antrean ini > 0 secara konsisten, artinya jaringan atau CPU mengalami bottleneck (flow control aktif).
• wsrep_cert_failures: Jumlah transaksi yang gagal karena konflik sertifikasi. Nilai yang tinggi menunjukkan adanya kontensi data yang tinggi pada tabel tertentu.
• Innodb_buffer_pool_wait_free: Menunjukkan apakah ukuran InnoDB Buffer Pool sudah memadai atau sering melakukan flush disk.

10. Checklist Penerapan Produksi & Kesimpulan

Gunakan checklist berikut sebelum merilis kluster MariaDB Galera ke lingkungan produksi:

• Konfigurasi bind-address dan firewall (Port 3306, 4567, 4568, 4444) aman dari akses publik.
• Pengguna SST menggunakan kata sandi yang kuat dan unik.
• innodb_buffer_pool_size telah disesuaikan dengan 75% kapasitas RAM server.
• Parameter innodb_autoinc_lock_mode = 2 aktif di seluruh node.
• Mekanisme pemantauan (monitoring) dengan Prometheus dan Grafana terpasang untuk metrik wsrep_*.
• Prosedur pencadangan harian (backup strategy) menggunakan mariabackup terotomatisasi via Cron.

Dengan mengikuti panduan komprehensif ini, Anda telah membangun arsitektur basis data MariaDB Galera Cluster yang memiliki ketersediaan tinggi, tahan terhadap kegagalan node, dan siap menghadapi beban transaksi aplikasi enterprise berskala masif.