L
MySQL • Literally Web ID

Arsitektur High Availability MySQL 8.4 dengan InnoDB Cluster dan ProxySQL

⏱️ 15 menit baca • 📅 12 Oct 2026 • 👁️ 1 views
Arsitektur High Availability MySQL 8.4 dengan InnoDB Cluster dan ProxySQL

1. Konteks Industri & Analisis Akar Masalah

Di era aplikasi berbasis web skala besar, modern microservices, dan platform e-commerce dengan transaksi jutaan per detik, kegagalan database (database downtime) adalah skenario mimpi buruk yang dapat melumpuhkan seluruh lini bisnis. Pendekatan tradisional dengan model Primary-Replica (Master-Slave) tunggal memiliki kerentanan struktural yang tinggi. Ketika node Primary mengalami crash akibat lonjakan traffic, gangguan jaringan, atau kegagalan perangkat keras (hardware failure), proses failover manual atau semi-otomatis sering kali memakan waktu menit bahkan jam. Akibatnya, terjadi Read/Write bottleneck, inkonsistensi data, dan hilangnya ribuan transaksi berharga.

Selain itu, aplikasi modern sering kali mengirimkan seluruh operasi SQL (baik SELECT untuk pembacaan maupun INSERT/UPDATE/DELETE untuk penulisan) langsung ke satu titik database. Hal ini menyebabkan utilisasi CPU dan RAM pada node utama melonjak drastis, sementara node-node replika hanya duduk diam menunggu siklus sinkronisasi yang lambat (asynchronous replication lag). Kondisi ini menciptakan latensi tinggi pada aplikasi backend (seperti PHP/Laravel, Go, atau Node.js) dan memperburuk pengalaman pengguna akhir.

Sebelum penerapan arsitektur High Availability modern, infrastruktur web sering kali menderita masalah:

  • Single Point of Failure (SPOF): Kematian server database utama berarti sistem down total.
  • Replication Lag: Data yang dibaca dari replica sering kali basi (stale data) karena penundaan sinkronisasi asynchronous.
  • Manual Intervention: Administrator sistem harus melakukan intervensi manual untuk mempromosikan replika baru, yang memicu human error.

Setelah penerapan arsitektur MySQL 8.4 InnoDB Cluster yang dikombinasikan dengan ProxySQL, sistem bertransformasi menjadi ekosistem yang resilien:

  • Zero Downtime Failover: Jika node utama mati, Group Replication secara otomatis memilih primary baru dalam hitungan detik tanpa kehilangan data (multi-master conflict resolution dan paxos consensus).
  • Intelligent Query Routing: ProxySQL secara otomatis memecah (split) query: operasi penulisan (INSERT/UPDATE/DELETE) diarahkan ke Primary, sedangkan operasi pembacaan (SELECT) didistribusikan secara merata ke seluruh node Replica.
  • Automatic Node Discovery: ProxySQL memantau kesehatan node secara real-time; jika sebuah node gagal, ProxySQL menghentikan pengiriman query ke node tersebut secara instan.

2. Konsep Inti & Deep Dive Arsitektur

Arsitektur yang kita bangun melibatkan dua komponen inti tingkat enterprise: MySQL InnoDB Cluster dan ProxySQL.

MySQL InnoDB Cluster

InnoDB Cluster adalah solusi high availability bawaan MySQL yang mengintegrasikan tiga teknologi powerful:

  1. MySQL Server & InnoDB Storage Engine: Sebagai fondasi penyimpanan data transaksional.
  2. MySQL Group Replication: Mesin replikasi yang menyediakan toleransi kesalahan berbasis kelompok (group communication engine). Menggunakan protokol berbasis Paxos, Group Replication memastikan bahwa transaksi hanya akan di-commit jika mayoritas node di dalam kluster telah menyetujuinya (distributed state machine replication).
  3. MySQL Shell: Antarmuka administratif canggih untuk mengelola siklus hidup kluster (dba.createCluster(), cluster.addInstance(), dll.).

ProxySQL

ProxySQL adalah high-performance, high-availability, protocol-aware MySQL proxy yang berdiri di antara aplikasi backend (seperti Nginx/PHP-FPM, Go microservices) dan kluster database. ProxySQL bertindak sebagai smart load balancer yang memahami protokol MySQL di tingkat paket, memungkinkan pemeriksaan, modifikasi, dan perutean query secara cerdas berdasarkan pola (regex) atau aturan hostgroup.

Visualisasi Alur Arsitektur (ASCII Flow Chart)

+-------------------------------------------------------------------------+
|                         Web & Application Servers                       | 
|                   (Nginx, PHP-FPM, Node.js, Go Backend)                 | 
+-------------------------------------------------------------------------+
                                     |
                         [ MySQL Protocol (Port 3306) ]
                                     v
+-------------------------------------------------------------------------+
|                              ProxySQL Tier                              | 
|                     (Query Routing, Read/Write Split)                   | 
+-------------------------------------------------------------------------+
          |                                                   |
          | [Write: INSERT, UPDATE, DELETE]                   | [Read: SELECT]
          v                                                   v
+-----------------------+                         +-----------------------+
|    MySQL Node 1       | <--- Group Replication  |    MySQL Node 2       |
|    (Primary / RW)     |                         |    (Secondary / RO)   |
+-----------------------+                         +-----------------------+
          ^                                                   ^
          |                  Paxos Consensus                  |
          +---------------------------------------------------+
                                     ^
                                     |
                          +-----------------------+
                          |    MySQL Node 3       |
                          |    (Secondary / RO)   |
                          +-----------------------+

3. Perbandingan Komparatif / Analisis Pendekatan

Untuk memahami mengapa kombinasi ini menjadi standar emas industri, mari kita bandingkan dengan pendekatan arsitektur database lainnya:

Parameter Perbandingan MySQL Traditional Asynchronous Replication MySQL Master-Master (Active-Active klasik) MySQL 8.4 InnoDB Cluster + ProxySQL
Consistency Level Rendah (Risiko stale reads & lag) Sangat Rendah (Konflik write sering terjadi) Tinggi (Strong Consistency via Paxos/Group Replication)
Failover Mechanism Manual / Script Eksternal rentan split-brain Manual / Kompleks Otomatis (Automatic Failover dalam detik)
Query Splitting Membutuhkan logika di kode aplikasi Membutuhkan logic di aplikasi Otomatis di layer ProxySQL tanpa ubah kode aplikasi
Resource Overhead Rendah Sedang Sedang-Tinggi (Membutuhkan RAM ekstra untuk Group Replication buffer)
Complex Setup Sangat Mudah Sulit & Berbahaya Terstandarisasi via MySQL Shell

[!WARNING] Hindari penggunaan arsitektur Master-Master tradisional berbasis log-slave-updates tanpa mesin konsensus yang valid karena sangat rentan terhadap split-brain syndrome dan korupsi data permanen.


4. Prasyarat Sistem & Persiapan Lingkungan

Sebelum memulai instalasi, pastikan Anda telah menyiapkan 3 unit Virtual Private Server (VPS) atau bare-metal yang menjalankan sistem operasi Ubuntu 24.04 LTS atau Debian 12, dengan spesifikasi minimum per node:

  • CPU: 2 vCPU
  • RAM: 4 GB (Sangat disarankan untuk stabilitas Group Replication)
  • Storage: SSD NVMe 50 GB
  • Jaringan: Jaringan privat lokal (LAN) dengan latensi < 2ms antar node.

Konvensi IP Address & Hostname

  • Node 1 (DB-Primary): 10.0.0.11 (Hostname: db01) - Berperan sebagai bootstrap node
  • Node 2 (DB-Replica 1): 10.0.0.12 (Hostname: db02)
  • Node 3 (DB-Replica 2): 10.0.0.13 (Hostname: db03)
  • ProxySQL Node: 10.0.0.20 (Hostname: proxy01) - Dapat digabung dengan load balancer web.

Persiapan Konfigurasi Hostname & /etc/hosts

Lakukan pada ketiga node database dan proxy:

sudo hostnamectl set-hostname db01 # Sesuaikan dengan node masing-masing (db01, db02, db03, proxy01)
sudo tee -a /etc/hosts <<EOF
10.0.0.11 db01
10.0.0.12 db02
10.0.0.13 db03
10.0.0.20 proxy01
EOF

5. Panduan Implementasi Langkah demi Langkah

Langkah 5.1: Instalasi MySQL 8.4 LTS pada Ketiga Node

Jalankan perintah berikut pada db01, db02, dan db03:

sudo apt update && sudo apt upgrade -y
sudo apt install -y wget lsb-release gnupg

# Unduh MySQL Apt Repository Configurator
wget https://dev.mysql.com/get/mysql-apt-config_0.30.1-1_all.deb
sudo dpkg -i mysql-apt-config_0.30.1-1_all.deb
# Pilih: MySQL Server & Cluster -> mysql-8.4-lts -> OK

sudo apt update
sudo apt install -y mysql-server mysql-shell

Langkah 5.2: Konfigurasi MySQL Server (/etc/mysql/mysql.conf.d/override.cnf)

Group Replication membutuhkan pengaturan spesifik pada file konfigurasi MySQL. Buat file override.cnf pada ketiga node database (db01, db02, db03):

[mysqld]
server-id                 = 11          # Ganti menjadi 12 untuk db02, 13 untuk db03
bind-address              = 0.0.0.0
report-host               = db01        # Ganti sesuai hostname node masing-masing

# -- InnoDB Cluster & Group Replication Mandatory Settings --
default_authentication_plugin = caching_sha2_password
enforce_gtid_consistency  = ON
gtid_mode                 = ON
master_info_repository    = TABLE
relay_log_info_repository = TABLE
binlog_checksum           = NONE
log_slave_updates         = ON
log_bin                   = binlog
binlog_format             = ROW
transaction_write_set_extraction = XXHASH64

# -- Group Replication Specifics --
group_replication_group_name = "a1b2c3d4-e5f6-7890-abcd-ef0123456789"
group_replication_start_on_boot = OFF
group_replication_local_address = "10.0.0.11:33061"  # Sesuaikan IP node
group_replication_group_seeds = "10.0.0.11:33061,10.0.0.12:33061,10.0.0.13:33061"
group_replication_bootstrap_group = OFF

Restart layanan MySQL setelah mengubah konfigurasi:

sudo systemctl restart mysql

Langkah 5.3: Inisialisasi MySQL InnoDB Cluster via MySQL Shell

Akses MySQL Shell dari db01 untuk membuat kluster:

mysqlsh root@localhost

Di dalam prompt MySQL Shell, jalankan perintah JavaScript berikut:

// Beralih ke mode SQL atau gunakan objek dba\js

// 1. Periksa apakah instance siap untuk Group Replication
dba.checkInstanceConfiguration('root@db01:3306');

// 2. Jika ada parameter yang kurang, perbaiki secara otomatis
dba.configureInstance('root@db01:3306');

// 3. Buat kluster baru
var cluster = dba.createCluster('myInnoDBCluster');

// 4. Tambahkan node db02 dan db03 ke dalam kluster
cluster.addInstance('root@db02:3306');
cluster.addInstance('root@db03:3306');

// 5. Periksa status kluster
cluster.status();

Langkah 5.4: Konfigurasi ProxySQL pada Node proxy01

Install ProxySQL pada proxy01 (10.0.0.20):

wget https://repo.proxysql.com/ProxySQL/proxysql-2.8.x/repo_pub_key.asc
sudo apt-key add repo_pub_key.asc
echo "deb https://repo.proxysql.com/ProxySQL/proxysql-2.8.x/ubuntu $(lsb_release -sc) ./" | sudo tee /etc/apt/sources.list.d/proxysql.list
sudo apt update && sudo apt install -y proxysql
sudo systemctl start proxysql

Akses admin interface ProxySQL (default credentials: admin / admin):

mysql -u admin -padmin -h 127.0.0.1 -P 6032

Masukkan konfigurasi server database ke dalam ProxySQL:

-- Masukkan node database ke dalam mysql_servers
INSERT INTO mysql_servers(hostgroup_id, hostname, port) VALUES (10, '10.0.0.11', 3306);
INSERT INTO mysql_servers(hostgroup_id, hostname, port) VALUES (20, '10.0.0.12', 3306);
INSERT INTO mysql_servers(hostgroup_id, hostname, port) VALUES (20, '10.0.0.13', 3306);

LOAD MYSQL SERVERS TO RUNTIME;
SAVE MYSQL SERVERS TO DISK;

-- Tambahkan user database yang memiliki hak akses dari proxy
-- Buat user khusus proxysql di MySQL Cluster terlebih dahulu via MySQL Shell
-- CREATE USER 'proxysql_mon'@'%' IDENTIFIED BY 'StrongMonitorPassword123!';
-- GRANT SELECT ON performance_schema.* TO 'proxysql_mon'@'%';
-- FLUSH PRIVILEGES;

INSERT INTO mysql_users(username, password, default_hostgroup) VALUES ('app_user', '*HASHED_PASSWORD_OR_PLAIN', 10);
LOAD MYSQL USERS TO RUNTIME;
SAVE MYSQL USERS TO DISK;

-- Konfigurasi Query Rules untuk Read/Write Splitting
INSERT INTO mysql_query_rules (rule_id, active, match_pattern, destination_hostgroup, apply)
VALUES (1, 1, '^SELECT.*FOR UPDATE$', 10, 1);

INSERT INTO mysql_query_rules (rule_id, active, match_pattern, destination_hostgroup, apply)
VALUES (2, 1, '^SELECT', 20, 1);

LOAD MYSQL QUERY RULES TO RUNTIME;
SAVE MYSQL QUERY RULES TO DISK;

6. Bedah Kode & Penjelasan Detail Baris Kunci

Mari bedah parameter krusial dalam file konfigurasi /etc/mysql/mysql.conf.d/override.cnf:

  • enforce_gtid_consistency = ON dan gtid_mode = ON: Global Transaction Identifiers wajib diaktifkan agar setiap transaksi memiliki ID unik lintas kluster, esensial untuk melacak posisi replikasi secara akurat tanpa bergantung pada file binlog tradisional.
  • binlog_format = ROW: Group Replication mewajibkan format berbasis baris (row-based replication) untuk menjamin determinisme saat transaksi direplikasi ke seluruh node.
  • group_replication_group_seeds: Berisi daftar IP seluruh node dalam kluster. Parameter ini digunakan oleh node baru atau node yang baru reboot untuk melakukan discovery phase dan bergabung kembali ke dalam topologi Paxos.

7. Skenario Produksi & Studi Kasus Dunia Nyata

Pada lingkungan produksi dengan beban tinggi (misalnya platform e-commerce saat Flash Sale):

  1. Aplikasi Backend (Node.js/Go): Mengarahkan koneksi database bukan ke IP MySQL langsung, melainkan ke 10.0.0.20:6033 (port front-end ProxySQL).
  2. Pemisahan Trafik: Transaksi checkout (INSERT INTO orders ...) otomatis masuk ke Hostgroup 10 (Primary db01). Katalog produk (SELECT * FROM products ...) didistribusikan secara Round-Robin atau Least Connections ke Hostgroup 20 (db02 dan db03).
  3. Kapasitas Skalabilitas: Jika pembacaan melonjak, Anda cukup menambahkan node db04 dan memasukkannya ke Hostgroup 20 di ProxySQL tanpa mengubah satu baris pun pada kode aplikasi.

8. Common Pitfalls, Anti-Patterns & Solusi

[!IMPORTANT] Kesalahan Fatal #1: Mengabaikan Latensi Jaringan Privat. Group Replication sangat sensitif terhadap network jitter. Jika latensi antar node > 10ms, transaksi akan mengalami timeout dan node akan keluar dari kluster (auto-eviction). Selalu gunakan jaringan privat dengan koneksi dedicated.

[!WARNING] Kesalahan Fatal #2: Kapasitas RAM yang Tidak Memadai. Menjalankan Group Replication di bawah 2GB RAM pada MySQL 8.4 akan memicu OOM Killer kernel Linux karena alokasi memori tambahan untuk buffer konsensus Paxos.


9. Benchmark, Metrik Kinerja & Tuning Performa

Untuk menguji performa kluster, gunakan tool benchmarking seperti sysbench:

# Inisialisasi data test sysbench melalui ProxySQL (Port 6033)
sysbench oltp_read_write \
  --mysql-host=10.0.0.20 \
  --mysql-port=6033 \
  --mysql-user=app_user \
  --mysql-password=SecretPassword \
  --mysql-db=test \
  --table-size=1000000 \
  prepare

# Jalankan benchmark beban tinggi
sysbench oltp_read_write \
  --mysql-host=10.0.0.20 \
  --mysql-port=6033 \
  --mysql-user=app_user \
  --mysql-password=SecretPassword \
  --mysql-db=test \
  --tables=10 \
  --table-size=1000000 \
  --threads=64 \
  --time=300 \
  run

Perhatikan metrik transactions: 95th percentile latency pada hasil akhir sysbench. Angka di bawah 15ms menunjukkan konfigurasi kluster dan ProxySQL berjalan optimal.


10. Checklist Penerapan Produksi & Kesimpulan

Sebelum merilis arsitektur ini ke lingkungan Live Production, pastikan checklist berikut terpenuhi:

  • Firewall (UFW / iptables) dikonfigurasi hanya mengizinkan port 3306, 33061, 6032, dan 6033 dari subnet internal aplikasi.
  • Backup otomatis harian dikonfigurasi menggunakan mysqlsh dump utility (dba.backup()).
  • Monitoring kesehatan ProxySQL dan MySQL terintegrasi dengan Prometheus dan Grafana.
  • Uji coba skenario Node Failure (mematikan paksa db01) telah dilakukan dan failover berlangsung < 5 detik.

Dengan mengimplementasikan MySQL 8.4 InnoDB Cluster dan ProxySQL, Anda telah membangun fondasi infrastruktur data enterprise yang sangat tersedia, tahan banting, dan siap menghadapi skala traffic tertinggi tanpa kompromi.

🏷️ Tags: #Nginx #High Concurrency #Performance #Sysadmin #Web Server