Tuning Performa MariaDB Galera Cluster untuk High Availability Finansial

1. Konteks Industri & Analisis Akar Masalah

Dalam lanskap industri teknologi finansial (Fintech), perbankan digital, dan payment gateway modern, ketersediaan tinggi (High Availability) dan konsistensi data yang mutlak (Strong Consistency) bukanlah sekadar opsi kosmetik, melainkan fondasi hukum dan bisnis yang tidak bisa ditawar. Kegagalan basis data sekecil apa pun—misalnya split-brain yang berujung pada duplikasi saldo atau lost update pada transaksi transfer dana—dapat berakibat fatal pada kerugian finansial, sanksi regulasi, hilangnya kepercayaan nasabah, serta runtuhnya reputasi institusi.

Secara historis, arsitektur Master-Slave tradisional dengan replikasi asinkron atau semi-sinkron rentan terhadap Single Point of Failure (SPOF) dan masalah replication lag. Ketika Master mengalami crash mendadak di tengah lonjakan transaksi tinggi, proses failover manual maupun otomatis sering kali menyisakan gap transaksi yang belum tersinkronisasi. Hal ini memicu inkonsistensi saldo rekening yang melanggar prinsip ACID (Atomicity, Consistency, Isolation, Durability).

MariaDB Galera Cluster hadir sebagai solusi multi-master synchronous replication berbasis teknologi certification-based replication (Galera Library). Dengan model ini, setiap node di dalam kluster dapat menerima operasi tulis (write operations) secara bersamaan, memastikan bahwa data disalin secara sinkron ke seluruh node sebelum transaksi dinyatakan commit. Namun, penerapan Galera Cluster pada sistem finansial dengan latensi rendah dan throughput tinggi menuntut konfigurasi parameter yang sangat presisi.

Bottleneck performa yang sering ditemui di dunia nyata meliputi:

• Latensi Jaringan (Inter-Node Latency): Sinkronisasi sinkron membutuhkan komunikasi jaringan yang sangat cepat. Lonjakan latensi antar-node langsung mendegradasi performa Commit Latency.
• Konflik Sertifikasi (Certification Conflicts / Certification Failures): Pada skenario high concurrency di mana banyak transaksi mengubah baris tabel yang sama secara simultan, tingkat kegagalan sertifikasi meningkat drastis, memicu rollback massal dan lonjakan retry query dari aplikasi backend.
• IO Bottleneck pada InnoDB Buffer Pool: Ukuran buffer pool yang tidak sesuai dengan working set size memicu disk thrashing yang memperlambat proses Write-Set Replication.

Sebelum vs Sesudah Penerapan

• Sebelum (Traditional Master-Slave / Async): Sering terjadi replication lag hingga hitungan detik, risiko kehilangan data (data loss) saat failover, waktu pemulihan (Recovery Time Objective / RTO) mencapai 15–30 menit, dan konsistensi data rentan saat beban puncak.
• Sesudah (Tuning MariaDB Galera Cluster untuk Finansial): Tercapainya RTO dan RPO (Recovery Point Objective) mendekati nol (Zero-Downtime), replikasi sinkron berbasis sertifikat, eliminasi split-brain melalui arbiter/quorum dinamis, serta konsistensi transaksional ACID yang mutlak di seluruh node.

2. Konsep Inti & Deep Dive Arsitektur

MariaDB Galera Cluster menggabungkan dua komponen utama: mesin penyimpanan MariaDB InnoDB dan Galera Cluster Plugin (wsrep API). Berbeda dengan replikasi tradisional yang mengirimkan statement atau row-based binary log secara asinkron, Galera menggunakan protokol replikasi grup berbasis certification-based replication yang dikombinasikan dengan Total Order Isolation (TOI).

Alur Kerja di Balik Layar (Under the Hood)

1. Local Execution: Klien mengirimkan query SQL ke Node A. Transaksi dieksekusi secara lokal di dalam thread engine InnoDB.
2. Certification Phase: Sebelum transaksi di-commit, node menghasilkan Write-Set yang berisi kunci baris yang diubah dan nilai perubahannya. Write-Set ini dikirimkan secara multicast ke seluruh node lain di dalam kluster melalui lapisan komunikasi grup (GCOMM).
3. Global Ordering & Validation: Setiap node menerima Write-Set tersebut dan melakukan validasi sertifikasi (certification test) secara paralel. Tes ini memeriksa apakah ada konflik dengan transaksi lain yang sedang diproses. Jika terjadi konflik pada baris yang sama, transaksi dengan urutan global yang lebih lambat akan dibatalkan (rollback).
4. Commit / Replication: Jika lolos sertifikasi, Write-Set diaplikasikan ke database lokal di setiap node, dan transaksi dinyatakan berhasil (committed).

+-------------------------------------------------------------+
|                        CLIENT APPLICATION                   |
+-------------------------------------------------------------+
       |                                           |
       | (1. Write Query)                          | (Read Query)
       v                                           v
+-----------------------+               +---------------------+
|      NODE A           |               |      NODE B         |
|  (Multi-Master Write) |               |   (Read-Only /      |
|                       |               |    Local Read)      |
+-----------------------+               +---------------------
       |                                
       | (2. Broadcast Write-Set via GCOMM) 
       +--------------------------------+
       |                                |
       v                                v
+---------------+               +---------------+
|  NODE C (WS)  |               |  NODE D (WS)  |
+---------------+               +---------------+

3. Perbandingan Komparatif / Analisis Pendekatan

Untuk memilih arsitektur basis data finansial yang paling optimal, tabel berikut menyajikan perbandingan mendalam antara MariaDB Galera Cluster, MySQL InnoDB Cluster (Group Replication), dan Master-Slave Tradisional.

[!WARNING] Pada sistem finansial, hindari penggunaan arsitektur Multi-Master aktif-aktif jika aplikasi backend Anda tidak dirancang untuk menangani Deadlock dan Certification Failures (Error 1213 / 40001). Pendekatan terbaik adalah mengarahkan seluruh write traffic ke satu node utama melalui load balancer (HAProxy/ProxySQL), sementara node lain bertugas sebagai failover otomatis dan read replicas berlatensi nol.

4. Prasyarat Sistem & Persiapan Lingkungan

Sebelum melakukan instalasi dan tuning, pastikan infrastruktur memenuhi standar spesifikasi produksi kelas finansial:

Spesifikasi Minimum Hardware (Per Node)

• CPU: Minimal 8 Core / 16 vCPU (Intel Xeon Gold / AMD EPYC dengan instruksi AES-NI aktif).
• RAM: Minimal 32 GB ECC RAM (Alokasikan 50-60% untuk InnoDB Buffer Pool).
• Storage: NVMe SSD enterprise dengan dukungan IOPS tinggi (> 20.000 IOPS Read/Write) dan fitur Power Loss Protection (PLP).
• Network: Jaringan privat dedicated minimal 1 Gbps (Direkomendasikan 10 Gbps dengan latensi antar-node < 2ms).

Prasyarat Software & Sistem Operasi

• OS: Ubuntu Server 22.04 LTS atau Rocky Linux 9 (Disable SELinux / Set ke permissive, matikan Firewall bawaan atau konfigurasikan port Galera).
• Database: MariaDB Server 10.11 LTS (Versi enterprise-grade dengan dukungan wsrep API yang matang).

Konfigurasi Jaringan & Firewall

Port utama yang wajib dibuka pada firewall internal antar-node:

• 3306/tcp: Port standar MariaDB untuk klien dan aplikasi backend.
• 4567/tcp: Port komunikasi replikasi Galera (GCOMM).
• 4568/tcp: Port transfer status antar-node (State Snapshot Transfer - SST).
• 4444/tcp: Port inkremental transfer state (Incremental State Transfer - IST).

5. Panduan Implementasi Langkah demi Langkah

Berikut adalah panduan lengkap konfigurasi MariaDB Galera Cluster di lingkungan produksi Linux Ubuntu 22.04 LTS.

Langkah 1: Instalasi Repositori dan MariaDB Server

Jalankan perintah berikut pada ketiga node kluster (misal: db-node1, db-node2, db-node3):

# Update sistem dan pasang dependensi dasar
sudo apt update && sudo apt upgrade -y
sudo apt install apt-transport-https curl software-properties-common wget -y

# Tambahkan GPG Key dan Repository resmi MariaDB 10.11
sudo mkdir -p /etc/apt/keyrings
sudo curl -o /etc/apt/keyrings/mariadb-keyring.pgp 'https://mariadb.org/mariadb_release_signing_key.gpg'

cat <<EOF | sudo tee /etc/apt/sources.list.d/mariadb.sources
X-Repomd-Name: MariaDB
Types: deb
URIs: https://mirrors.xtom.nl/mariadb/repo/10.11/ubuntu
Suites: jammy
Components: main main/debug
Signed-By: /etc/apt/keyrings/mariadb-keyring.pgp
EOF

# Instal MariaDB Server dan Galera 4
sudo apt update
sudo apt install mariadb-server galera-4 -y

Langkah 2: Konfigurasi File wsrep.cnf untuk Produksi Finansial

Buat file konfigurasi khusus Galera di /etc/mysql/mariadb.conf.d/60-galera.cnf. Pastikan Anda mengganti IP address sesuai dengan node masing-masing.

[mysqld]
# Pengaturan Engine Utama
binlog_format=ROW
default-storage-engine=innodb
innodb_autoinc_lock_mode=2
innodb_doublewrite=1

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

# Kluster Name dan Alamat Node
wsrep_cluster_name="fintech_galera_cluster"
wsrep_cluster_address="gcomm://192.168.10.11,192.168.10.12,192.168.10.13"

# Identitas Node (Ganti IP ini pada masing-masing node)
wsrep_node_address="192.168.10.11"
wsrep_node_name="db-node1"

# Metode State Snapshot Transfer (SST) menggunakan MariaBackup
wsrep_sst_method=mariabypass
wsrep_sst_auth="sst_user:SecurePassWord123!"

# Pengaturan Optimasi Transaksi Finansial
innodb_buffer_pool_size=16G
innodb_log_file_size=2G
innodb_flush_log_at_trx_commit=1
innodb_file_per_table=1
innodb_flush_method=O_DIRECT

# Pengaturan Jaringan & Timeout Galera
wsrep_slave_threads=8
evs.keepalive_period = PT1S
evs.inactive_timeout = PT15S
evs.suspect_timeout = PT5S

Langkah 3: Inisialisasi Kluster Pertama (Bootstrap)

Hentikan layanan MariaDB pada semua node, lalu inisialisasi bootstrap hanya pada node pertama (db-node1):

# Hentikan layanan di semua node
sudo systemctl stop mariadb

# Bootstrap kluster pertama kali pada node 1
sudo galera_new_cluster

Verifikasi bahwa kluster telah aktif dan jumlah komponen kluster bernilai 1:

-- Masuk ke MariaDB shell
sudo mysql -u root -p

-- Jalankan query status
SHOW STATUS LIKE 'wsrep_cluster_size';

Output yang diharapkan:

+--------------------+-------+
| Variable_name      | Value |
+--------------------+-------+
| wsrep_cluster_size | 1     |
+--------------------+-------+

Langkah 4: Bergabung dengan Node Kedua dan Ketiga

Pada db-node2 dan db-node3, jalankan layanan MariaDB secara normal:

sudo systemctl start mariadb

Periksa kembali status kluster dari salah satu node:

SHOW STATUS LIKE 'wsrep_%';

Pastikan wsrep_cluster_size bernilai 3 dan wsrep_cluster_status bernilai Primary. Konfigurasikan juga akun autentikasi SST untuk MariaBackup di dalam database:

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

6. Bedah Kode & Penjelasan Detail Baris Kunci

Mari kita bedah parameter krusial dalam file konfigurasi 60-galera.cnf yang menentukan kestabilan sistem finansial:

1. binlog_format=ROW:
   • Fungsi: Mewajibkan format binary log berbasis baris. Galera memerlukan tingkat granularitas tingkat baris (row-level) untuk membangun Write-Set yang akurat dan melakukan validasi sertifikasi.
2. innodb_autoinc_lock_mode=2 (Interleaved Lock Mode):
   • Fungsi: Sangat penting untuk performa multi-master. Mode 2 meniadakan table-level auto-increment locking yang ketat, memungkinkan beberapa node menghasilkan nilai auto-increment secara bersamaan tanpa menyebabkan antrean blokir (table locking).
3. innodb_flush_log_at_trx_commit=1 & innodb_doublewrite=1:
   • Fungsi: Standar emas untuk kepatuhan ACID pada sistem finansial. Nilai 1 memastikan setiap transaksi di-flush ke disk secara fisik sebelum konfirmasi sukses dikirim ke klien, mencegah kehilangan data sekecil apa pun saat terjadi power failure mendadak.
4. wsrep_slave_threads=8:
   • Fungsi: Menentukan jumlah thread paralel yang digunakan oleh node untuk mengaplikasikan Write-Set yang diterima dari node lain. Pada server dengan prosesor 16 vCPU, angka 8 memaksimalkan pemrosesan paralel dan menurunkan replication lag secara signifikan.
5. evs.keepalive_period = PT1S & evs.suspect_timeout = PT5S:
   • Fungsi: Mengatur sensitivitas deteksi heartbeat antar-node. Untuk jaringan finansial berlatensi rendah, mempercepat timeout deteksi membantu kluster mengisolasi node yang bermasalah secara instan dan mencegah split-brain berkepanjangan.

7. Skenario Produksi & Studi Kasus Dunia Nyata

Dalam sebuah studi kasus implementasi Core Payment Engine yang menangani 5.000 transaksi per detik (TPS) saat flash sale atau akhir bulan, arsitektur backend Go/Node.js dihubungkan melalui ProxySQL ke MariaDB Galera Cluster.

Tantangan Nyata

Lonjakan transaksi secara bersamaan pada tabel saldo akun (accounts) memicu lonjakan error sertifikasi Galera: Error 1213: Deadlock found when trying to get lock; try restarting transaction.

Solusi Arsitektural

1. Penerapan Retry Logic di Backend (Idempotent Transactions): Setiap transaksi finansial diberi UUIDempotency Key di level aplikasi. Jika terjadi Certification Failure (Error 1213 atau Galera error 1062), aplikasi backend secara otomatis melakukan exponential backoff retry sebanyak 3 kali.
2. Pemisahan Tabel Hot-Spot: Tabel penghitungan saldo utama dipecah menggunakan sharding logis atau pendekatan ledger-based accounting (append-only table), di mana transaksi tidak langsung memperbarui satu baris saldo secara destruktif, melainkan menambahkan baris mutasi debit/kredit baru yang kemudian direkap secara asinkron.
3. ProxySQL Read-Write Splitting: Semua query pembacaan saldo (SELECT balance FROM accounts) diarahkan ke Read-Only Replicas atau node sekunder, sementara query penulisan (UPDATE accounts SET balance = balance - X) diarahkan secara eksklusif ke Node Utama (Master 1) untuk meminimalisasi ruang lingkup konflik sertifikasi.

8. Common Pitfalls, Anti-Patterns & Solusi

Kesalahan umum yang sering dilakukan oleh administrator pemula dalam mengelola Galera Cluster:

• Anti-Pattern 1: Menjalankan Transaksi Sangat Besar (Large Transactions)
  • Dampak: Transaksi yang mengubah ratusan ribu baris dalam satu perintah UPDATE tunggal menghasilkan Write-Set berukuran raksasa yang melampaui batas memori wsrep_max_ws_size (default 2GB), memicu crash node seketika.
  • Solusi: Selalu pecah transaksi besar menjadi batch kecil (misal: 500 baris per iterasi transaksi menggunakan loop di aplikasi).
• Anti-Pattern 2: Menambah Node Genap Tanpa Arbiter
  • Dampak: Membangun kluster dengan 2 node menciptakan kerentanan split-brain parah ketika koneksi jaringan terputus (masing-masing node menganggap dirinya mayoritas dan kehilangan konsistensi).
  • Solusi: Selalu gunakan jumlah node ganjil (3 atau 5), atau gunakan Garbd (Galera Arbitrator Daemon) ringan di server terpisah untuk mencukupi kuorum minimal.
• Anti-Pattern 3: Mengabaikan Pemantauan Status wsrep
  • Dampak: Administrator tidak menyadari ketika sebuah node keluar dari kluster (Non-Primary State), mengakibatkan aplikasi backend terus mengirim query ke node yang terisolasi.
  • Solusi: Pasang Prometheus MySQL Exporter dan buat Grafana Dashboard dengan Alerting aktif untuk memantau metrik wsrep_cluster_status, wsrep_local_cert_failures, dan wsrep_flow_control_paused.

9. Benchmark, Metrik Kinerja & Tuning Performa

Untuk memastikan Galera Cluster siap menghadapi beban finansial nyata, lakukan pengujian beban menggunakan sysbench.

Langkah Pengujian Sysbench

# Inisialisasi data test sebanyak 10 tabel, masing-masing 1 juta baris
sysbench /usr/share/sysbench/oltp_read_write.lua \
  --mysql-host=192.168.10.11 \
  --mysql-user=fintech_user \
  --mysql-password=SecurePassWord123! \
  --mysql-db=fintech_db \
  --table-size=1000000 \
  --tables=10 \
  prepare

# Jalankan benchmark beban tinggi selama 300 detik dengan 64 thread
sysbench /usr/share/sysbench/oltp_read_write.lua \
  --mysql-host=192.168.10.11 \
  --mysql-user=fintech_user \
  --mysql-password=SecurePassWord123! \
  --mysql-db=fintech_db \
  --table-size=1000000 \
  --tables=10 \
  --threads=64 \
  --time=300 \
  --rate=0 \
  run

Interpretasi Metrik Kunci (SHOW GLOBAL STATUS)

• wsrep_local_cert_failures: Jika angka ini melonjak tinggi selama benchmark, artinya terjadi banyak konflik transaksi. Solusinya adalah mendesain ulang skema indeks tabel atau mengurangi kontensi baris di aplikasi.
• wsrep_flow_control_paused: Menunjukkan persentase waktu node dihentikan sementara karena node lain tertinggal (lagging). Nilai ideal harus mendekati 0.0 (0%). Jika nilai melebihi 0.05 (5%), periksa performa disk I/O atau bandwidth jaringan antar-node.

10. Checklist Penerapan Produksi & Kesimpulan

Sebelum merilis sistem finansial berbasis MariaDB Galera Cluster ke lingkungan Live Production, pastikan seluruh poin dalam checklist berikut telah terpenuhi:

• Infrastruktur Jaringan: Latensi antar-node stabil di bawah 2 ms dengan koneksi privat dedicated.
• Konfigurasi Quorum: Minimal 3 node aktif atau penggunaan Garbd untuk mencegah split-brain.
• Parameter InnoDB & ACID: innodb_flush_log_at_trx_commit=1, innodb_doublewrite=1, dan innodb_autoinc_lock_mode=2 telah diterapkan.
• Keamanan Akses: Enkripsi SSL/TLS diaktifkan untuk komunikasi kluster (wsrep_provider_options="socket.ssl=yes"), kredensial root aman, dan SST user terisolasi.
• Backup & Disaster Recovery: MariaBackup rutin terjadwal dengan pengujian pemulihan (restore test) berkala.
• Monitoring & Alerting: Prometheus dan Grafana aktif memantau metrik kritis seperti wsrep_cluster_size dan wsrep_flow_control_paused.

Dengan mengikuti panduan komprehensif ini secara disiplin, infrastruktur basis data finansial Anda akan mencapai tingkat ketersediaan tinggi, ketahanan terhadap kegagalan jaringan, serta konsistensi data mutlak yang memenuhi standar audit industri keuangan global.