Membangun Klaster Database MySQL High Availability Menggunakan Orchestrator

1. Konteks Industri & Analisis Akar Masalah

Dalam lanskap arsitektur web modern, ketersediaan tinggi (High Availability / HA) pada lapisan database adalah fondasi mutlak yang tidak dapat ditawar. Ketika sebuah aplikasi enterprise menghadapi lonjakan traffic—baik dari frontend berbasis arsitektur SPA, layanan backend berbasis Node.js/Go, maupun pemrosesan asinkron melalui sistem antrean seperti RabbitMQ atau Redis—kegagalan pada database tunggal (Single Point of Failure / SPOF) akan mengakibatkan kelumpuhan total sistem. Dampaknya tidak hanya berupa kerugian finansial yang masif, tetapi juga rusaknya reputasi bisnis secara permanen.

Secara historis, administrator infrastruktur mengandalkan solusi failover berbasis Virtual IP (VIP) dengan Keepalived atau menggunakan MySQL Master-Master replication yang rentan terhadap fenomena split-brain. Split-brain terjadi ketika dua node database mengira diri mereka adalah master yang sah secara bersamaan, mengakibatkan korupsi data yang fatal (divergence data). Dalam skenario produksi modern dengan target Recovery Time Objective (RTO) di bawah 10 detik dan Recovery Point Objective (RPO) nol (zero data loss), pendekatan manual atau skrip bash generik tidak lagi memadai.

Sebelum penerapan klaster HA berbasis Orchestrator dengan replikasi semi-synchronous, kondisi infrastruktur umumnya digambarkan sebagai berikut:

• Sebelum Penerapan: Menggunakan Active-Passive sederhana. Jika master utama (Primary) mengalami kernel panic, database crash, atau kegagalan hardware, tim on-call harus melakukan deteksi manual, mempromosikan replika secara manual, dan memperbarui konfigurasi DNS atau koneksi aplikasi. Proses ini memakan waktu 5 hingga 30 menit, menyebabkan downtime yang tidak dapat diterima oleh SLA bisnis modern (99.99%).
• Sesudah Penerapan: Klaster dikelola secara otonom oleh GitHub Orchestrator yang memantau topologi replikasi secara real-time. Jika node primary gagal, Orchestrator secara otomatis mendeteksi kegagalan, melakukan validasi status binlog, memilih replika yang paling mutakhir (most up-to-date), mempromosikannya menjadi master baru, dan mereconfigured node replika lainnya tanpa intervensi manusia. RTO terpangkas menjadi kurang dari 10 detik dengan jaminan zero data loss berkat konfigurasi MySQL Semi-Synchronous Replication.

2. Konsep Inti & Deep Dive Arsitektur

Untuk mencapai zero data loss, arsitektur ini menggabungkan dua komponen kritikal: MySQL Semi-Synchronous Replication dan GitHub Orchestrator Topology Management.

Alur Kerja Replikasi Semi-SynchronousPada replikasi asinkron standar, primary mengirimkan event binary log (binlog) ke replika tanpa menunggu konfirmasi penerimaan, sehingga risiko kehilangan data (data loss) sangat tinggi jika primary mati mendadak. Pada replikasi semi-sync:

1. Klien mengirimkan transaksi tulis (INSERT/UPDATE/DELETE) ke MySQL Primary.
2. Primary menulis transaksi tersebut ke binlog lokal dan menyimpannya ke storage (disk).
3. Primary mengirimkan binlog event tersebut melalui jaringan ke setidaknya satu MySQL Replica.
4. Sebelum Primary mengirimkan respons sukses (ACK) kembali ke klien aplikasi, Primary wajib menunggu konfirmasi tertulis (ACK) dari Replica bahwa event tersebut telah diterima dan ditulis ke relay log lokal mereka.
5. Setelah ACK diterima dari replika, Primary mengonfirmasi transaksi sukses kepada klien.

Peran GitHub Orchestrator

Orchestrator adalah alat manajemen topologi replikasi MySQL yang bersifat stateless (dari sudut pandang data, karena state disimpan di backend database MySQL/SQLite sendiri). Orchestrator melakukan polling terus-menerus ke seluruh node database untuk memetakan pohon replikasi, mendeteksi kegagalan, dan mengeksekusi proses failover otonom.

+-------------------------------------------------------------------------+
|                        GitHub Orchestrator UI / CLI                     |
+-------------------------------------------------------------------------+
       | (Continuous Polling & Health Checks via TCP 3306)
       v
+-----------------------+              +-----------------------+
|      MySQL Node 1     |  (Binlog)    |      MySQL Node 2     |
|    (Primary / Write)  | -----------> |   (Replica / Read)    |
|      Semi-Sync ACK    | <----------- |      Semi-Sync ACK    |
+-----------------------+              +-----------------------+
       |                                           ^
       | (Promoted upon failure)                   | (Re-points to new primary)
       +-------------------------------------------+
                                                   |
+-----------------------+                          |
|      MySQL Node 3     | -------------------------+
|    (Replica / Read)   |
+-----------------------+

3. Perbandingan Komparatif / Analisis Pendekatan

Berikut adalah analisis perbandingan mendalam antara tiga pendekatan high availability MySQL di lingkungan enterprise:

Trade-off Sumber Daya: Penggunaan Semi-Synchronous menambah latensi tulis sebesar waktu Round Trip Time (RTT) jaringan antara primary dan replika terdekat (umumnya 1-5ms pada jaringan datacenter lokal). Namun, trade-off ini sangat sepadan demi menjamin kepatuhan integritas data finansial atau transaksional.

4. Prasyarat Sistem & Persiapan Lingkungan

Sebelum memulai instalasi, pastikan lingkungan infrastruktur memenuhi spesifikasi teknis berikut:

• Sistem Operasi: Ubuntu Server 22.04 LTS (atau RHEL 9 / Rocky Linux 9)
• Topologi Minimal: 3 Node Server terpisah (untuk mencegah split-brain pada orchestrator dan quorum)
  • db-node-01: IP 192.168.10.11 (Initial Primary)
  • db-node-02: IP 192.168.10.12 (Replica 1)
  • db-node-03: IP 192.168.10.13 (Replica 2 / Orchestrator Backend)
• Software: MySQL Server 8.0+, GitHub Orchestrator (v3.2.6+)
• Jaringan: Port TCP 3306 (MySQL) dan Port TCP 3000 (Orchestrator UI/API) harus terbuka antar node dalam satu Virtual Private Cloud (VPC).

5. Panduan Implementasi Langkah demi Langkah

Langkah 1: Konfigurasi MySQL Server pada Ketiga Node

Edit file konfigurasi MySQL /etc/mysql/mysql.conf.d/mysqld.cnf pada ketiga node. Sesuaikan parameter server_id secara unik untuk setiap node.

[mysqld]
server-id               = 11
bind-address            = 0.0.0.0
report-host             = db-node-01

# Binary Logging Configuration
log-bin                 = mysql-bin
binlog-format           = ROW
expire_logs_days        = 7
max_binlog_size         = 500M

# GTID Configuration (Mandatory for Orchestrator)
gtid-mode               = ON
enforce-gtid-consistency = ON

# InnoDB Tuning & Durability
innodb_flush_log_at_trx_commit = 1
sync_binlog             = 1
innodb_buffer_pool_size = 4G

# Semi-Synchronous Replication Plugins
plugin-load-add         = semisync_master.so
plugin-load-add         = semisync_slave.so

# Default Semi-Sync Settings
rpl_semi_sync_master_enabled = 1
rpl_semi_sync_slave_enabled  = 1
rpl_semi_sync_master_timeout = 10000

[!IMPORTANT] Pastikan Anda mengganti nilai server-id menjadi 12 untuk db-node-02 dan 13 untuk db-node-03. Ubah juga report-host sesuai hostname masing-masing node.

Restart layanan MySQL di semua node:

sudo systemctl restart mysql
sudo systemctl enable mysql

Langkah 2: Pembuatan User Replikasi dan Orchestrator

Masuk ke konsol MySQL pada node pertama (db-node-01) dan jalankan perintah SQL berikut untuk membuat akun replikasi dan akun administratif untuk Orchestrator:

-- Buat user replikasi
CREATE USER 'replicator'@'%' IDENTIFIED WITH mysql_native_password BY 'StrongReplPassword123!';
GRANT REPLICATION SLAVE ON *.* TO 'replicator'@'%';

-- Buat user untuk Orchestrator
CREATE USER 'orchestrator'@'%' IDENTIFIED WITH mysql_native_password BY 'OrchSecurePass456!';
GRANT SUPER, REPLICATION CLIENT, PROCESS, SELECT, INSERT, UPDATE, DELETE, DROP, ALTER ON *.* TO 'orchestrator'@'%';
GRANT RELOAD ON *.* TO 'orchestrator'@'%';
GRANT REPLICATION SLAVE ON *.* TO 'orchestrator'@'%';
FLUSH PRIVILEGES;

Jalankan perintah yang sama (khusus pembuatan user orchestrator dan replikasi) pada db-node-02 dan db-node-03.

Langkah 3: Konfigurasi Replikasi Awal (Bootstrap)

Pada db-node-02 dan db-node-03, arahkan replikasi ke db-node-01 menggunakan GTID:

STOP SLAVE;
RESET SLAVE ALL;
CHANGE MASTER TO 
  MASTER_HOST='192.168.10.11', 
  MASTER_USER='replicator', 
  MASTER_PASSWORD='StrongReplPassword123!', 
  MASTER_AUTO_POSITION=1;
START SLAVE;

Verifikasi status replikasi di node replika:

SHOW SLAVE STATUS\G

Pastikan Slave_IO_Running: Yes dan Slave_SQL_Running: Yes bernilai Yes.

Langkah 4: Instalasi dan Konfigurasi GitHub Orchestrator

Unduh dan instal paket Orchestrator pada node db-node-03 (atau server dedicated management):

cd /tmp
wget https://github.com/github/orchestrator/releases/download/v3.2.6/orchestrator-3.2.6-linux-amd64.tar.gz
tar -zxvf orchestrator-3.2.6-linux-amd64.tar.gz
sudo mv orchestrator /usr/local/bin/
sudo mkdir -p /etc/orchestrator

Buat file konfigurasi /etc/orchestrator/orchestrator.conf.json:

{
  "Debug": true,
  "EnableHTTPAPI": true,
  "HTTPAPIAuthBasic": false,
  "Port": 3000,
  "ListenAddress": "0.0.0.0",
  "Backend": "mysql",
  "MySQLOrchestratorHost": "192.168.10.13",
  "MySQLOrchestratorPort": 3306,
  "MySQLOrchestratorDatabase": "orchestrator",
  "MySQLOrchestratorUser": "orchestrator",
  "MySQLOrchestratorPassword": "OrchSecurePass456!",
  "DefaultReplicaServerId": 3333,
  "RecoveryPollPeriodSeconds": 5,
  "ClearSevereErrorReplicaIntervalMinutes": 10,
  "FailureDetectionPeriod": "2s",
  "RecoverMasterClusterFilters": [
    "*"
  ],
  "CandidateReplicaPriority": {
    "^db-node-02": 10,
    "^db-node-03": 5
  },
  "ActionHooksEnabled": true,
  "PostFailoverSteps": [
    "echo 'Failover completed successfully for {failureCluster}' >> /var/log/orchestrator_failover.log"
  ]
}

Inisialisasi skema database backend untuk Orchestrator:

mysql -h 192.168.10.13 -u orchestrator -pOrchSecurePass456! -e "CREATE DATABASE IF NOT EXISTS orchestrator;"
orchestrator --config /etc/orchestrator/orchestrator.conf.json -i

Jalankan Orchestrator sebagai systemd service di /etc/systemd/system/orchestrator.service:

[Unit]
Description=GitHub Orchestrator Service
After=network.target mysql.service

[Service]
User=root
ExecStart=/usr/local/bin/orchestrator --config /etc/orchestrator/orchestrator.conf.json http
Restart=always
RestartSec=5

[Install]
WantedBy=multi-user.target

Aktifkan dan jalankan service:

sudo systemctl daemon-reload
sudo systemctl enable orchestrator
sudo systemctl start orchestrator

6. Bedah Kode & Penjelasan Detail Baris Kunci

• gtid-mode = ON & enforce-gtid-consistency = ON: Global Transaction Identifiers sangat krusial bagi Orchestrator. Tanpa GTID, proses promosi replika memerlukan kalkulasi posisi binlog (MASTER_LOG_FILE dan MASTER_LOG_POS) secara manual yang rentan terhadap galat (offset mismatch). Dengan GTID, setiap transaksi memiliki ID unik global yang melintasi topologi replikasi secara otomatis.
• rpl_semi_sync_master_enabled = 1: Mengaktifkan modul semi-sync pada sisi primary, memastikan setiap transaksi tulis tidak akan mengembalikan ACK sukses ke klien sebelum minimal satu replika mencatat data tersebut.
• CandidateReplicaPriority: Parameter JSON dalam konfigurasi Orchestrator ini menentukan hierarki prioritas pemilihan master baru saat failover terjadi. Node dengan nilai prioritas tertinggi (db-node-02 dengan nilai 10) akan dipilih terlebih dahulu oleh algoritma pemilihan master Orchestrator.

7. Skenario Produksi & Studi Kasus Dunia Nyata

Dalam lingkungan produksi berbeban tinggi (misalnya sistem e-commerce berskala besar yang memproses 10.000 QPS / Query Per Second), integrasi database HA ini dihubungkan dengan connection pool aplikasi (seperti ProxySQL atau HAProxy) di lapisan perantara.

[Aplikasi Backend Node.js / Go] ---> [ProxySQL (Port 6033)]
                                           |
                  +------------------------+------------------------+
                  | (Write Traffic)                                 | (Read Traffic)
                  v                                                 v
       [MySQL Primary (192.168.10.11)]                  [MySQL Replicas (Read Pool)]

Ketika Orchestrator mendeteksi kegagalan pada Primary, ProxySQL secara otomatis mendeteksi perubahan topologi melalui API Orchestrator atau health check berkala, kemudian memindahkan rute write traffic ke node primary yang baru dipromosikan tanpa mengganggu koneksi read pool aplikasi.

8. Common Pitfalls, Anti-Patterns & Solusi

1. Anti-Pattern: Menggunakan 2 Node saja untuk Klaster.
   • Masalah: Quorum tidak dapat dicapai jika salah satu node mati, mengakibatkan keputusan failover menjadi tidak deterministik.
   • Solusi: Selalu gunakan minimal 3 node independen atau gunakan Raft-based consensus topology.
2. Pitfall: Mengabaikan sync_binlog = 1 dan innodb_flush_log_at_trx_commit = 1 demi mengejar performa IOPS.
   • Masalah: Ketika terjadi pemadaman listrik mendadak (hard power loss), transaksi yang diklaim 'sukses' dapat hilang dari disk lokal, merusak integritas data meskipun replikasi semi-sync aktif.
   • Solusi: Selalu set kedua parameter tersebut ke nilai 1 pada node primary.
3. Pitfall: Timeout Semi-Sync Terlalu Singkat (rpl_semi_sync_master_timeout).
   • Masalah: Jika jaringan mengalami jitter sesaat selama 1 detik dan timeout diset terlalu rendah (misal 1000ms), MySQL akan otomatis melakukan fallback ke mode asinkron, membuka celah data loss.
   • Solusi: Set timeout pada kisaran 10000ms (10 detik) hingga tak terbatas, tergantung pada toleransi latensi aplikasi.

9. Benchmark, Metrik Kinerja & Tuning Performa

Pengujian performa klaster dapat dilakukan menggunakan tool benchmark sysbench untuk mensimulasikan beban OLTP (Online Transaction Processing):

sysbench /usr/share/sysbench/oltp_read_write.lua \
  --mysql-host=192.168.10.11 \
  --mysql-user=orchestrator \
  --mysql-password=OrchSecurePass456! \
  --mysql-db=test \
  --tables=10 \
  --table-size=100000 \
  --threads=64 \
  --time=60 \
  run

Metrik Kinerja yang Diamati:

• Transactions Per Second (TPS): Pastikan penurunan TPS pada mode semi-sync tidak melebihi 15-20% dibandingkan mode asinkron murni.
• Latency 99th Percentile (p99): Ukur dampak penambahan ACK network round-trip terhadap respons latensi kueri tulis.
• Tuning Lanjutan: Sesuaikan innodb_io_capacity dan innodb_io_capacity_max sesuai dengan spesifikasi perangkat keras NVMe SSD yang digunakan pada server database.

10. Checklist Penerapan Produksi & Kesimpulan

Sebelum merilis sistem klaster ini ke lingkungan produksi publik, pastikan seluruh item dalam checklist berikut terpenuhi:

• Semua node menggunakan sinkronisasi waktu NTP yang akurat.
• Firewall (UFW / Firewalld) mengunci akses port 3306 hanya untuk subnet internal aplikasi dan Orchestrator.
• Kredensial database menggunakan strong password dan tidak menggunakan akun root default.
• Simulasi Chaos Engineering (mematikan node primary secara paksa menggunakan sudo echo c > /proc/sysrq-trigger) telah diuji dan terbukti berhasil melakukan failover otomatis tanpa kehilangan data.
• Monitoring Prometheus & Grafana dikonfigurasi untuk memantau metrik rpl_semi_sync_master_status dan orchestrator_instance_is_master.

Dengan menerapkan arsitektur MySQL High Availability berbasis GitHub Orchestrator dan Replikasi Semi-Synchronous ini, infrastruktur enterprise Anda kini memiliki ketahanan militer terhadap kegagalan infrastruktur, menjamin ketersediaan layanan tanpa kompromi.