Optimasi Performa MariaDB Galera Cluster untuk High-Throughput OLTP

1. Konteks Industri & Analisis Akar Masalah

Dalam lanskap arsitektur web modern yang menuntut ketersediaan tinggi (high availability) dan throughput transaksi yang masif, infrastruktur database sering kali menjadi titik kegagalan tunggal (single point of failure atau SPOF) sekaligus hambatan performa utama (bottleneck). Aplikasi enterprise, platform e-commerce berskala besar, sistem pembayaran finansial, dan layanan SaaS real-time berbasis backend Node.js, Go, atau PHP-FPM tidak lagi dapat mentolerir downtime operasional yang disebabkan oleh pemeliharaan server database konvensional atau kegagalan perangkat keras mendadak.

Secara tradisional, arsitektur Master-Slave (atau Master-Replica tunggal) mendominasi lanskap implementasi MySQL dan MariaDB. Namun, pola ini memiliki kelemahan mendasar dalam skenario High-Throughput OLTP (Online Transaction Processing): replikasi bersifat asinkron atau semi-sinkron, yang membuka peluang terjadinya replication lag dan kehilangan data (data loss) jika node Master mengalami crash sebelum transaksi direplikasi ke Slave. Lebih jauh lagi, ketika node Master gagal, proses failover memerlukan intervensi manual atau skrip pemantauan eksternal yang kompleks, sering kali mengakibatkan pemulihan yang lambat dan inkonsistensi data.

Bottleneck performa umum pada arsitektur klasik meliputi:

• Write Bottleneck: Semua operasi penulisan (INSERT, UPDATE, DELETE) terpusat pada satu node Master, membatasi skalabilitas horizontal.
• Read/Write Contention: Beban baca yang dialihkan ke node Slave sering kali membaca data yang usang (stale reads) akibat latensi replikasi asinkron.
• Lock Contention pada InnoDB Buffer Pool: Penggunaan konfigurasi memori yang tidak optimal menyebabkan tingginya page flushing ke disk mekanis atau SSD berkualitas rendah.
• Network Partition (Split-Brain): Kegagalan jaringan yang memecah klaster menjadi dua bagian terisolasi yang sama-sama menerima transaksi, mengakibatkan korupsi data yang fatal.

[!IMPORTANT] Menerapkan MariaDB Galera Cluster mengubah paradigma ini melalui replikasi berbasis sertifikasi (certification-based replication), di mana konsistensi data dijamin secara sinkron di tingkat kelompok (virtually synchronous), memungkinkan arsitektur Multi-Master sejati.

Perbandingan Kondisi: Sebelum vs Sesudah Penerapan MariaDB Galera Cluster

| Parameter Sistem | Sebelum (Traditional Master-Slave) | Sesudah (MariaDB Galera Cluster Multi-Master) | |---|---|---|> | RTO (Recovery Time Objective) | Menit hingga Jam (Manual/Semi-Automated Failover) | Mendekati Nol (Otomatis via Quorum & Component State) | | RPO (Recovery Point Objective) | > 0 (Risiko kehilangan data pada replikasi asinkron) | 0 (Zero-Loss Transaction Certification) | | Skalabilitas Tulis (Write Scalability) | Terbatas pada kapasitas satu node Master | Skalabel secara horizontal hingga batas latensi jaringan antar node | | Konsistensi Data | Eventual Consistency (Potensi Stale Reads / Split-Brain) | Strong Consistency (Galera Certification Model) | | Penanganan Konflik Tulis | Tidak ada deteksi otomatis di level engine | Deteksi konflik baris otomatis dengan Cluster-level Abort |

2. Konsep Inti & Deep Dive Arsitektur

MariaDB Galera Cluster adalah solusi penyimpanan berarsitektur multi-master high-availability untuk MariaDB, yang menggabungkan InnoDB storage engine dengan Galera Cluster Library. Inti dari arsitektur Galera bukanlah replikasi berbasis pernyataan (statement-based) atau baris (row-based) tradisional MySQL, melainkan replikasi berbasis kelompok (group communication) yang menggunakan protokol total order broadcast.

Alur Eksekusi Transaksi (Under the Hood)

1. Local Execution: Aplikasi mengirimkan query tulis ke salah satu node di dalam klaster. Transaksi dimulai secara lokal di dalam InnoDB engine node tersebut.
2. Write Set Generation: Selama eksekusi, semua perubahan baris dicatat ke dalam struktur data khusus yang disebut Write Set. Write set ini berisi kunci baris yang diubah dan nilai baru (image).
3. Replication & Certification (The Magic Step): Saat sesi transaksi mencapai tahap COMMIT, node tersebut tidak langsung menulis ke disk secara permanen. Node membungkus write set dan menyiarkannya (broadcast) ke seluruh node lain di dalam klaster menggunakan protokol multicast/unicast berbasis Galera (berjalan di atas lapisan wsrep).
4. Certification Test: Setiap node menerima write set secara bersamaan dalam urutan total yang sama (total order). Setiap node melakukan certification check secara independen di memori: apakah ada transaksi lain yang sedang atau telah berjalan yang mengubah kunci baris yang sama?
   • Jika Ya (Konflik Terdeteksi): Transaksi ditolak (aborted) pada node asalnya, dan klien menerima galat deadlock/serialization failure.
   • Jika Tidak (Aman): Transaksi disertifikasi, dimasukkan ke dalam antrean apply, dan node melakukan commit lokal.
5. State Transfer: Jika sebuah node baru bergabung (State Snapshot Transfer / SST atau Incremental State Transfer / IST), node tersebut menyinkronkan seluruh riwayat atau delta transaksi dari node donor yang aktif.

+-------------+         1. Query SQL         +-----------------------+
| Client App  | ---------------------------> | MariaDB Node 1        |
+-------------+                              +-----------------------+
                                                        | 2. Local InnoDB Tx
                                                        v
+-------------+     4. Broadcast Write Set   +-----------------------+
| MariaDB     | <--------------------------- | Write Set Generation  |
| Node 3      |                              +-----------------------+
+-------------+                                         |
       |                                                v
       | 5. Cert Check & Apply               +-----------------------+
       +------------------------------------ | MariaDB Node 2        |
                                             +-----------------------+

3. Perbandingan Komparatif / Analisis Pendekatan

Dalam mendesain sistem basis data enterprise, pemilihan teknologi replikasi harus didasarkan pada analisis mendalam mengenai trade-off sumber daya komputasi, jaringan, dan latensi.

Analisis Pendekatan Replikasi Database

[!TIP] Galera Cluster sangat unggul untuk lingkungan Data Center tunggal atau Multi-AZ dengan latensi ultra-rendah. Jangan pernah menempatkan node Galera di antar benua dengan latensi >50ms, karena mekanisme certification timeout akan memicu pengeluaran node (flapping) dari klaster.

4. Prasyarat Sistem & Persiapan Lingkungan

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

• OS: Ubuntu Server 22.04 LTS / Rocky Linux 9 (Direkomendasikan kernel Linux minimal 5.15+).
• Topologi Minimal: 3 Node Mandiri (Node1, Node2, Node3) untuk memastikan kuorum (quorum) valid (mencegah split-brain).
• Jaringan: IP Statis, resolusi DNS internal yang handal, dan firewall yang mengizinkan port komunikasi Galera.
• Port yang Harus Dibuka:
  • 3306/tcp: Port standar MariaDB untuk klien dan koneksi aplikasi.
  • 4567/tcp: Port replikasi Galera Cluster (komunikasi antar node/GCS).
  • 4568/tcp: Port untuk Incremental State Transfer (IST).
  • 4444/tcp: Port untuk State Snapshot Transfer (SST) via rsync/mariabackup.

Verifikasi Awal dan Penyiapan Repository

Jalankan perintah berikut pada seluruh node klaster untuk memperbarui sistem dan menambahkan repositori resmi MariaDB 10.11 LTS:

# Perbarui sistem operasi
sudo apt update && sudo apt upgrade -y

# Instal dependensi esensial
sudo apt install -y curl software-properties-common gnupg2 ufw rsync

# Tambahkan GPG Key dan Repositori MariaDB 10.11
curl -Ls https://downloads.mariadb.com/MariaDB/mariadb_repo_setup \
  | sudo bash -s -- --mariadb-server-version=10.11

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

# Hentikan layanan MariaDB untuk konfigurasi awal
sudo systemctl stop mariadb

5. Panduan Implementasi Langkah demi Langkah

Konfigurasi Galera dikendalikan melalui parameter wsrep di dalam file konfigurasi server MariaDB. Kita akan menggunakan file konfigurasi terpisah di /etc/mysql/mariadb.conf.d/60-galera.cnf agar terstruktur.

Konfigurasi Produksi: Node 1 (192.168.10.11)

Buat dan isi file konfigurasi pada Node 1:

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

# Pengaturan Koneksi
bind-address=0.0.0.0
max_connections=2048

# Pengaturan wsrep Galera Provider
wsrep_on=ON
wsrep_provider=/usr/lib/galera/libgalera_smi.so

# Alamat Klaster (Daftar IP seluruh node)
wsrep_cluster_address="gcomm://192.168.10.11,192.168.10.12,192.168.10.13"

# Nama Klaster
wsrep_cluster_name="galera_production_cluster"

# Identitas Node Ini (Sesuaikan IP per node)
wsrep_node_address="192.168.10.11"
wsrep_node_name="mariadb-node-1"

# Metode State Snapshot Transfer (Gunakan mariabackup untuk performa optimal)
wsrep_sst_method=mariabackup
wsrep_sst_auth="sstrpl_user:SecureSSTPassword2023!"

[!NOTE] Untuk Node 2 (192.168.10.12) dan Node 3 (192.168.10.13), gunakan konfigurasi yang sama persis, namun ubah parameter wsrep_node_address dan wsrep_node_name sesuai identitas masing-masing node.

Membuat Pengguna SST di MariaDB

Sebelum bootstrapping klaster, buat pengguna autentikasi SST yang diperlukan oleh mariabackup agar node dapat menyinkronkan data dengan aman. Jalankan perintah ini pada salah satu node lokal:

-- Masuk ke konsol MariaDB
sudo mysql -u root

-- Buat pengguna SST dengan hak akses minimal yang diperlukan
CREATE USER 'sstrpl_user'@'localhost' IDENTIFIED BY 'SecureSSTPassword2023!';
GRANT RELOAD, PROCESS, LOCK TABLES, REPLICATION CLIENT ON *.* TO 'sstrpl_user'@'localhost';
FLUSH PRIVILEGES;
EXIT;

Bootstrapping Klaster Pertama Kali

Klaster Galera memerlukan satu node inisialisasi untuk membentuk kuorum awal. Proses ini hanya dilakukan pada Node 1.

# Bootstrap klaster pada node pertama
sudo galera_new_cluster

# Verifikasi bahwa node pertama telah aktif sebagai klaster baru
sudo mysql -u root -e "SHOW STATUS LIKE 'wsrep_cluster_size';"

Output yang diharapkan menunjukkan ukuran klaster (wsrep_cluster_size) bernilai 1.

Bergabung dengan Klaster pada Node 2 & Node 3

Pada Node 2 dan Node 3, jalankan layanan MariaDB secara normal menggunakan systemctl:

# Jalankan layanan MariaDB pada node pengikut
sudo systemctl start mariadb

# Verifikasi penggabungan klaster
sudo mysql -u root -e "SHOW STATUS LIKE 'wsrep_cluster_size';"

Jika konfigurasi jaringan dan firewall benar, wsrep_cluster_size akan berubah menjadi 3 di semua node.

6. Bedah Kode & Penjelasan Detail Baris Kunci

Mari kita bedah parameter krusial dalam blok konfigurasi [mysqld] Galera:

• binlog_format=ROW: Wajib mutlak. Galera mengandalkan replikasi tingkat baris untuk merekam perubahan data secara presisi. Format STATEMENT atau MIXED akan menyebabkan kegagalan sinkronisasi replikasi.
• innodb_autoinc_lock_mode=2: Mengubah mode penguncian auto-increment menjadi interleaved lock mode. Hal ini memungkinkan beberapa node menghasilkan nilai AUTO_INCREMENT secara bersamaan tanpa mengunci tabel secara global, meningkatkan konkurensi tulis (write concurrency).
• innodb_doublewrite=1: Meskipun ada overhead penulisan disk, pengaturan ini mencegah korupsi halaman data (page corruption) saat terjadi kegagalan daya mendadak pada node fisik.
• wsrep_provider: Menunjuk langsung ke pustaka bersama (libgalera_smi.so) yang mengimplementasikan protokol replikasi grup Galera.
• wsrep_cluster_address: Menentukan daftar bootstrapping. Perhatikan awalan gcomm://. Kosongkan IP di dalam string ini hanya saat melakukan bootstrapping pertama kali menggunakan perintah galera_new_cluster.
• wsrep_sst_method=mariabackup: Menggunakan mariabackup untuk melakukan State Snapshot Transfer. Metode ini melakukan hot backup tanpa mengunci tabel secara keseluruhan, jauh lebih efisien dibandingkan metode lawas seperti rsync atau mysqldump pada database berukuran ratusan gigabyte.

7. Skenario Produksi & Studi Kasus Dunia Nyata

Dalam lingkungan produksi dengan lalu lintas tinggi (misalnya: platform e-commerce yang melayani 10.000 request/detik), arsitektur aplikasi harus dikombinasikan dengan load balancer database seperti ProxySQL atau HAProxy di hadapan Galera Cluster.

Arsitektur Routing Trafik Aplikasi

• Write Traffic (INSERT/UPDATE/DELETE): Dialirkan secara eksklusif ke satu node utama (Write Master) melalui ProxySQL untuk meminimalkan potensi Certification Failures (Deadlock akibat transaksi serentak pada baris yang sama dari node berbeda).
• Read Traffic (SELECT): Didistribusikan secara merata menggunakan algoritma Round-Robin atau Least Connections ke seluruh node klaster (Node 1, Node 2, Node 3) untuk memaksimalkan pemanfaatan sumber daya CPU dan RAM.

+------------------+
|  Backend Apps    |
|  (Node/Go/PHP)   |
+------------------+
         |
         v
+------------------+
| ProxySQL Cluster |
+------------------+
   |             |----
   | (Writes)    |    | (Reads)
   v             v    v
+-------+     +-------+     +-------+
| Node1 | <-> | Node2 | <-> | Node3 |
+-------+     +-------+     +-------+

8. Common Pitfalls, Anti-Patterns & Solusi

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

   • Dampak: Terjadi lonjakan wsrep_cert_failures, di mana transaksi sering dibatalkan karena modifikasi serentak pada baris tabel yang sama, menyebabkan latensi aplikasi melonjak.
   • Solusi: Arahkan transaksi tulis (OLTP writes) melalui satu node utama per sesi aplikasi, atau gunakan pembatasan antrean di tingkat aplikasi (application-level queue).

2. Pitfall: Mengabaikan Pengaturan Ukuran innodb_buffer_pool_size

   • Dampak: Terjadi disk swapping yang masif, memperlambat proses sertifikasi Galera dan memicu node timeout.
   • Solusi: Alokasikan hingga 70-80% dari total RAM fisik server secara eksklusif untuk innodb_buffer_pool_size pada setiap node klaster.

3. Kesalahan Fatal: Split-Brain Recovery yang Salah

   • Dampak: Ketika terjadi pemutusan jaringan, dua bagian klaster berjalan secara terpisah. Saat jaringan pulih, terjadi inkonsistensi data yang parah.
   • Solusi: Selalu gunakan jumlah node ganjil (3, 5, atau 7) agar kuorum tercapai dengan jelas (> 50%). Jika terjadi split-brain total, pilih node dengan posisi wsrep_local_state_uuid dan urutan transaksi tertinggi sebagai node bootstrap pemulihan.

9. Benchmark, Metrik Kinerja & Tuning Performa

Pengujian beban (load testing) pada MariaDB Galera Cluster harus dilakukan menggunakan perangkat benchmark standar industri seperti sysbench untuk mengukur metrik utama berikut:

Menjalankan Sysbench OLTP Read/Write Benchmark

# 1. Siapkan data uji sebesar 10 juta baris
sysbench /usr/share/sysbench/oltp_read_write.lua \
  --mysql-host=127.0.0.1 \
  --mysql-port=3306 \
  --mysql-user=root \
  --mysql-password=YourRootPassword \
  --mysql-db=test \
  --table-size=10000000 \
  --tables=10 prepare

# 2. Jalankan eksekusi benchmark selama 300 detik dengan 64 thread
sysbench /usr/share/sysbench/oltp_read_write.lua \
  --mysql-host=127.0.0.1 \
  --mysql-port=3306 \
  --mysql-user=root \
  --mysql-password=YourRootPassword \
  --mysql-db=test \
  --table-size=10000000 \
  --tables=10 \
  --threads=64 \
  --time=300 \
  --report-interval=10 run

Metrik Kinerja Utama yang Harus Dipantau via mysql CLI

-- Memeriksa ukuran klaster dan status keaktifan node
SHOW STATUS LIKE 'wsrep_cluster_size';

-- Memeriksa apakah node berada dalam status sinkron penuh
SHOW STATUS LIKE 'wsrep_local_state_comment';

-- Memantau tingkat kegagalan sertifikasi (Harus mendekati 0 % dari total transaksi)
SHOW STATUS LIKE 'wsrep_cert_failures';

-- Memantau antrean masuk (Flow Control: wsrep_flow_control_paused)
SHOW STATUS LIKE 'wsrep_flow_control_paused';

[!WARNING] Jika nilai wsrep_flow_control_paused bernilai lebih dari 0.05 (5%), ini mengindikasikan bahwa node tertentu mengalami lag dalam memproses write set, sehingga memicu perlambatan seluruh klaster. Periksa performa I/O disk dan latensi jaringan antar node segera.

10. Checklist Penerapan Produksi & Kesimpulan

Sebelum meluncurkan infrastruktur MariaDB Galera Cluster ke lingkungan produksi yang melayani pengguna akhir, pastikan Anda telah memverifikasi seluruh daftar periksa berikut:

• Topologi Kuorum: Minimal 3 node aktif dengan konfigurasi jaringan latensi rendah (<10ms).
• Konfigurasi Keamanan: Akses root dibatasi, akun SST dikonfigurasi dengan kredensial kuat, dan port internal Galera (4567, 4568, 4444) dibatasi hanya untuk IP internal klaster via UFW/iptables.
• Tuning InnoDB Buffer Pool: Alokasi RAM dioptimalkan sesuai kapasitas fisik server.
• Backup Otomatis: Skrip pencadangan berkala menggunakan mariabackup terjadwal via Cron diatur pada node terdedikasi.
• Monitoring & Alerting: Integrasi Prometheus dan Grafana dengan MariaDB Exporter untuk memantau metrik wsrep_cluster_size, wsrep_cert_failures, dan pemanfaatan disk secara real-time.
• Simulasi Disaster Recovery: Telah melakukan pengujian skenario hard kill pada salah satu node untuk memastikan proses failover otomatis dan reintegrasi berjalan mulus tanpa intervensi manual yang merusak data.

Penerapan MariaDB Galera Cluster memberikan pondasi basis data yang tangguh, konsisten, dan memiliki ketersediaan tinggi untuk aplikasi web high-throughput. Dengan pemahaman mendalam mengenai arsitektur sertifikasi, penanganan parameter wsrep yang tepat, serta manajemen lalu lintas aplikasi melalui proxy, sistem Anda siap menghadapi lonjakan transaksi skala enterprise.