Scaling MariaDB Enterprise: Master-Slave Replication dan Query Optimization

1. Konteks Industri & Analisis Akar Masalah

Dalam lanskap arsitektur web modern, basis data sering kali menjadi titik kegagalan tunggal (Single Point of Failure / SPOF) sekaligus bottleneck performa utama. Ketika sebuah platform digital bertransisi dari fase startup menuju enterprise, volume transaksi harian melonjak secara eksponensial. Permintaan baca (read requests) dari aplikasi backend—baik yang dibangun menggunakan Node.js, Go, maupun PHP-FPM—membebani mesin database tunggal hingga saturasi CPU dan kehabisan memori I/O.

Sebelum penerapan arsitektur Master-Slave Replication dan optimalisasi kueri tingkat lanjut, infrastruktur tipikal sering kali mengalami degradasi kinerja yang parah. Kueri kompleks yang tidak terindeks dengan baik melakukan full table scan, mengunci baris data terlalu lama, dan memicu antrean koneksi (connection pool exhaustion) pada web server seperti Nginx atau Apache. Kondisi Sebelum penerapan arsitektur terdistribusi ini ditandai dengan latensi API yang tinggi (mencapai ribuan milidetik), lonjakan beban CPU hingga 100%, serta kerentanan tinggi terhadap crash saat terjadi lonjakan trafik (traffic spikes).

Setelah penerapan strategi Master-Slave Replication dipadukan dengan optimalisasi InnoDB Buffer Pool dan analisis EXPLAIN, beban baca berhasil didistribusikan ke beberapa slave nodes (read-replicas), sementara master node secara eksklusif menangani operasi tulis (write operations). Hasilnya adalah penurunan latensi kueri rata-rata hingga 70%, peningkatan kapasitas throughput sistem secara keseluruhan, serta jaminan ketersediaan tinggi (High Availability) yang meminimalkan waktu henti (downtime) saat pemeliharaan sistem.

2. Konsep Inti & Deep Dive Arsitektur

Replikasi Master-Slave pada MariaDB bekerja dengan memindahkan beban tulis ke satu node utama (Master) dan menyalin perubahan data tersebut secara asinkron atau semi-sinkron ke satu atau lebih node sekunder (Slave).

Di balik layar, proses ini bergantung pada tiga komponen utama:

1. Binary Log (Binlog) pada Master: Setiap pernyataan SQL atau perubahan baris yang mengubah data dicatat secara berurutan ke dalam file binlog.
2. I/O Thread pada Slave: Thread ini berjalan di latar belakang pada node slave, terhubung ke master, dan meminta file binlog terbaru untuk kemudian dituliskan ke dalam Relay Log lokal.
3. SQL Thread pada Slave: Thread ini membaca Relay Log lokal dan mengeksekusi ulang pernyataan SQL atau event perubahan data tersebut pada database lokal slave.

Berikut adalah visualisasi alur data dalam arsitektur Master-Slave Replication:

+-------------------------------------------------------------+
|                     Client / Application                    |
+------------------------------+------------------------------+
                               |
          +--------------------+--------------------+
          | (Write Operations)                      | (Read Operations)
          v                                         v
+--------------------+                    +-------------------+
|    Master Node     |                    |    Slave Node     |
|  (MariaDB InnoDB)  |                    |  (MariaDB InnoDB) |
+---------+----------+                    +---------+---------+
          |                                           ^
          | (Binary Log / Binlog)                     | (I/O & SQL Thread)
          +-------------------------------------------+

Perbedaan mendasar antara Master-Slave Replication konvensional dan Galera Cluster terletak pada konsistensi dan konsensus. Galera menggunakan replikasi multi-master sinkron berbasis sertifikasi (gaps-based replication) yang ideal untuk ketersediaan tinggi mutlak dengan toleransi partisi jaringan, namun memiliki overhead tulis yang lebih tinggi karena latensi jaringan antar-node. Sebaliknya, Master-Slave sangat efisien untuk beban kerja dengan rasio baca-ke-tulis yang sangat tinggi (read-heavy workloads).

3. Perbandingan Komparatif / Analisis Pendekatan

Untuk menentukan arsitektur yang tepat, tabel berikut menyajikan perbandingan komprehensif antara Master-Slave Replication dan Galera Cluster:

4. Prasyarat Sistem & Persiapan Lingkungan

Sebelum memulai instalasi dan konfigurasi klaster MariaDB Enterprise, pastikan lingkungan sistem memenuhi spesifikasi dan prasyarat berikut:

• Sistem Operasi: Ubuntu Server 22.04 LTS atau RHEL 9 (Minimum 2 Node: 1 Master, 1 Slave).
• Hardware: Minimal 2 vCPU, 4 GB RAM, dan SSD NVMe untuk performa I/O optimal.
• Konektivitas Jaringan: Akses privat internal antar-node tanpa pembatasan firewall pada port default MariaDB (3306).
• Paket Software: MariaDB Server versi 10.11 LTS atau Enterprise Server terbaru.

Lakukan verifikasi awal pada kedua server dengan memperbarui repositori dan menginstal paket MariaDB:

sudo apt update && sudo apt upgrade -y
sudo apt install software-properties-common dirmngr apt-transport-https curl -y

5. Panduan Implementasi Langkah demi Langkah

Langkah 1: Konfigurasi Node Master (db-master)

Buka file konfigurasi MariaDB pada node master:

sudo nano /etc/mysql/mariadb.conf.d/50-server.cnf

Tambahkan atau sesuaikan parameter berikut pada blok [mysqld]:

[mysqld]
server-id               = 1
log_bin                 = /var/log/mysql/mariadb-bin.log
log_bin_index           = /var/log/mysql/mariadb-bin.index
binlog_format           = ROW
expire_logs_days        = 7
max_binlog_size         = 100M
bind-address            = 0.0.0.0
innodb_buffer_pool_size = 2G
innodb_flush_log_at_trx_commit = 1
innodb_file_per_table   = 1

Simpan file dan restart layanan MariaDB pada master:

sudo systemctl restart mariadb

Langkah 2: Membuat Pengguna Replikasi pada Master

Masuk ke shell MariaDB pada master:

sudo mariadb -u root -p

Jalankan perintah SQL berikut untuk membuat akun replikasi dan memberikan hak akses:

CREATE USER 'repl_user'@'%' IDENTIFIED BY 'S3cretReplP@ss2024!';
GRANT REPLICATION SLAVE ON *.* TO 'repl_user'@'%';
FLUSH PRIVILEGES;
FLUSH TABLES WITH READ LOCK;
SHOW MASTER STATUS;

Catat nilai File dan Position yang dihasilkan dari perintah SHOW MASTER STATUS. Contoh output: +--------------------+----------+--------------+------------------+ | File | Position | Binlog_Do_DB | Binlog_Ignore_DB | +--------------------+----------+--------------+------------------+ | mariadb-bin.000001 | 337 | | | +--------------------+----------+--------------+------------------+

Langkah 3: Backup Data Awal dan Restore ke Slave

Tanpa menutup sesi terminal master yang sedang melakukan READ LOCK, lakukan dump data dari terminal terpisah:

sudo mysqldump -u root -p --all-databases --master-data=2 > /tmp/db_backup.sql

Setelah dump selesai, kembali ke shell MariaDB master dan lepaskan kunci:

UNLOCK TABLES;

Salin file /tmp/db_backup.sql ke node slave (db-slave), lalu lakukan impor:

sudo mariadb -u root -p < /tmp/db_backup.sql

Langkah 4: Konfigurasi Node Slave (db-slave)

Buka file konfigurasi pada node slave:

sudo nano /etc/mysql/mariadb.conf.d/50-server.cnf

Sesuaikan parameter server-id (harus unik, misalnya 2) dan aktifkan read-only:

[mysqld]
server-id               = 2
relay-log               = /var/log/mysql/mysql-relay-bin
relay-log-index         = /var/log/mysql/mysql-relay-bin.index
log_bin                 = /var/log/mysql/mariadb-bin.log
binlog_format           = ROW
read_only               = 1
bind-address            = 0.0.0.0
innodb_buffer_pool_size = 2G
innodb_flush_log_at_trx_commit = 1

Restart layanan MariaDB pada slave:

sudo systemctl restart mariadb

Langkah 5: Menghubungkan Slave ke Master

Masuk ke shell MariaDB pada node slave dan jalankan perintah konfigurasi replikasi (sesuaikan nilai MASTER_LOG_FILE dan MASTER_LOG_POS dengan hasil SHOW MASTER STATUS sebelumnya):

STOP SLAVE;
CHANGE MASTER TO
  MASTER_HOST='IP_ADDRESS_MASTER',
  MASTER_USER='repl_user',
  MASTER_PASSWORD='S3cretReplP@ss2024!',
  MASTER_LOG_FILE='mariadb-bin.000001',
  MASTER_LOG_POS=337;
START SLAVE;

Verifikasi status replikasi:

SHOW SLAVE STATUS\G

[!IMPORTANT] Pastikan parameter Slave_IO_Running dan Slave_SQL_Running bernilai Yes. Jika bernilai No atau Connecting, periksa kembali kredensial jaringan, firewall, dan izin pengguna replikasi.

6. Bedah Kode & Penjelasan Detail Baris Kunci

Mari kita bedah beberapa parameter konfigurasi paling krusial dalam file 50-server.cnf:

• server-id = 1: Setiap server dalam topologi replikasi MariaDB wajib memiliki ID unik. ID ini digunakan oleh mesin penyimpanan untuk mencegah loop replikasi dan melacak asal perubahan data.
• binlog_format = ROW: Format replikasi berbasis baris (row-based) mencatat perubahan aktual pada setiap baris data alih-alih pernyataan SQL mentah. Ini jauh lebih aman dan deterministik dibandingkan format STATEMENT, terutama jika kueri menggunakan fungsi non-deterministik seperti NOW() atau UUID().
• read_only = 1: Diterapkan secara eksklusif pada node slave untuk mencegah aplikasi melakukan operasi INSERT, UPDATE, atau DELETE secara tidak sengaja langsung ke slave, yang akan merusak integritas data replikasi.
• innodb_flush_log_at_trx_commit = 1: Pengaturan ini memastikan bahwa log transaksi InnoDB di-flush ke disk pada setiap akhir transaksi commit. Ini memberikan tingkat durabilitas tertinggi dan mencegah kehilangan data saat terjadi kegagalan daya mendadak (power failure).

7. Skenario Produksi & Studi Kasus Dunia Nyata

Pada platform E-Commerce high-traffic dengan jutaan pengguna aktif harian, pemisahan beban database sangat menentukan kelangsungan operasional. Aplikasi backend berbasis Go dan Node.js dikonfigurasi menggunakan pola CQRS (Command Query Responsibility Segregation) sederhana pada tingkat koneksi database:

• Koneksi Tulis (Master): Digunakan untuk proses Checkout, pendaftaran pengguna, pembaruan keranjang belanja, dan manajemen inventaris stok produk.
• Koneksi Baca (Slave Pool): Digunakan untuk katalog produk, pencarian produk, ulasan pelanggan, dan dasbor analitik pelaporan.

Ketika terjadi lonjakan flash sale, lonjakan trafik baca sebesar 50.000 permintaan per detik diserap secara merata oleh 4 node slave menggunakan load balancer tingkat aplikasi, sementara master tetap stabil menangani 2.000 transaksi tulis per detik tanpa mengalami lock contention.

8. Common Pitfalls, Anti-Patterns & Solusi

1. Kesalahan 1: Mengabaikan Pengindeksan pada Kolom Foreign Key

   • Dampak: Setiap kali terjadi operasi penghapusan atau pembaruan pada tabel induk, slave akan melakukan full table scan pada tabel anak, menyebabkan lag replikasi yang masif.
   • Solusi: Selalu buat indeks pada setiap kolom yang bertindak sebagai foreign key.

2. Kesalahan 2: Menggunakan Format Binlog STATEMENT pada Lingkungan Kompleks

   • Dampak: Menyebabkan ketidakonsistenan data antara master dan slave akibat perbedaan waktu eksekusi atau penggunaan fungsi acak.
   • Solusi: Selalu tetapkan binlog_format = ROW untuk konsistensi data yang mutlak.

3. Kesalahan 3: Alokasi innodb_buffer_pool_size yang Melebihi Kapasitas RAM Fisik

   • Dampak: Memicu thrashing memori dan pertukaran swap ke disk, yang menurunkan kinerja database secara drastis.
   • Solusi: Alokasikan maksimal 70-80% dari total RAM fisik server untuk innodb_buffer_pool_size pada server yang didedikasikan khusus untuk database.

9. Benchmark, Metrik Kinerja & Tuning Performa

Untuk menguji ketahanan klaster MariaDB, gunakan utilitas benchmark bawaan sysbench:

-- Persiapan data uji sysbench
sysbench /usr/share/sysbench/oltp_read_write.lua \
  --mysql-host=192.168.1.50 \
  --mysql-user=root \
  --mysql-password=YourRootPassword \
  --mysql-db=test \
  --tables=10 \
  --table-size=100000 prepare

Jalankan pengujian performa baca pada node slave:

sysbench /usr/share/sysbench/oltp_read_only.lua \
  --mysql-host=192.168.1.51 \
  --mysql-user=root \
  --mysql-password=YourRootPassword \
  --mysql-db=test \
  --tables=10 \
  --table-size=100000 \
  --threads=64 \
  --time=60 run

Analisis metrik utama seperti Transactions Per Second (TPS), latensi rata-rata, dan pemanfaatan CPU. Lakukan tuning lanjutan pada parameter innodb_thread_concurrency dan table_open_cache berdasarkan hasil metrik tersebut.

[!TIP] Gunakan perintah SHOW ENGINE INNODB STATUS\G secara berkala untuk memantau metrik internal InnoDB seperti Buffer pool hit rate, aktivitas checkpointing, dan potensi deadlocks.

10. Checklist Penerapan Produksi & Kesimpulan

Sebelum meluncurkan klaster MariaDB Enterprise ke lingkungan produksi, pastikan seluruh item dalam checklist berikut telah terpenuhi:

• Konfigurasi server-id unik pada setiap node.
• Format binlog diatur ke ROW dengan pembersihan otomatis (expire_logs_days).
• Node slave dikunci dalam mode read_only = 1.
• Pengguna replikasi memiliki hak akses minimum yang diperlukan (REPLICATION SLAVE).
• Kebijakan backup otomatis harian dengan mariadb-dump atau xtrabackup telah aktif.
• Pemantauan real-time untuk Slave Lag dan pemanfaatan disk terintegrasi dengan sistem monitoring (Prometheus & Grafana).

Melalui penerapan arsitektur Master-Scale Replication yang dikombinasikan dengan optimalisasi kueri dan manajemen buffer pool yang tepat, infrastruktur basis data enterprise Anda akan mampu menangani lonjakan trafik ekstrem dengan ketersediaan tinggi, latensi minimal, dan integritas data yang terjaga.