L
MySQL • Literally Web ID

Arsitektur High Availability MySQL 8.4 dengan InnoDB Cluster dan ProxySQL

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

1. Konteks Industri & Analisis Akar Masalah

Dalam lanskap arsitektur web modern, ketersediaan tinggi (High Availability atau HA) bukan lagi sebuah kemewahan, melainkan fondasi mutlak yang harus dipenuhi oleh setiap sistem enterprise. Kegagalan basis data (database downtime) berdampak langsung pada kerugian finansial yang masif, rusaknya reputasi brand, serta terputusnya rantai layanan bagi pengguna akhir. Sebagian besar infrastruktur web modern menggunakan stack berbasis Nginx, PHP-FPM atau Node.js, serta caching layer dengan Redis. Namun, ketika basis data MySQL menjadi titik tunggal kegagalan (Single Point of Failure / SPOF), seluruh ketahanan arsitektur web tersebut runtuh seketika.

Secara tradisional, arsitektur replikasi MySQL menggunakan model Asynchronous Master-Slave. Model ini memiliki kelemahan fatal: replication lag yang tidak dapat diprediksi dan risiko kehilangan data (data loss) yang tinggi ketika master mengalami kegagalan mendadak sebelum transaksi sempat disinkronkan ke slave. Proses failover manual membutuhkan intervensi administrator, yang memakan waktu pemulihan (Recovery Time Objective / RTO) hingga berjam-jam.

Sebelum penerapan InnoDB Cluster dan ProxySQL, kondisi infrastruktur tipikal mengalami masalah-masalah berikut:

  • Downtime Akibat Failover Manual: Ketika node utama crash, aplikasi mengalami connection refused hingga DBA mengubah konfigurasi koneksi basis data secara manual pada aplikasi backend (Go/PHP/Node.js).
  • Split-Brain Syndrome: Konfigurasi failover otomatis yang tidak dikelola dengan benar sering kali menghasilkan dua node yang sama-sama mengklaim diri sebagai master, mengakibatkan korupsi data yang parah.
  • Beban Koneksi Berlebih (Connection Storm): Ribuan worker PHP-FPM atau proses Node.js membanjiri MySQL secara langsung, menghabiskan alokasi memori untuk thread cache dan menurunkan performa sistem secara drastis.
  • Ketidakseimbangan Beban Baca (Read Load Imbalance): Aplikasi mendistribusikan read query secara acak atau menumpuk pada satu slave saja, menyebabkan slave tersebut mengalami saturasi CPU dan I/O.

Setelah penerapan arsitektur High Availability MySQL 8.4 dengan InnoDB Cluster (berbasis Group Replication) dan ProxySQL sebagai intelligent database proxy, kondisi tersebut berubah drastis:

  • Failover Otomatis Tanpa Intervensi: Jika node primer gagal, Group Replication secara otomatis memilih node primer baru dalam hitungan detik (Automatic Distributed Recovery).
  • Routing Query Cerdas: ProxySQL memisahkan write query secara otomatis ke node Primary (RW) dan mendistribusikan read query ke node Secondary (RO) menggunakan algoritma weighted round-robin.
  • Connection Pooling: ProxySQL menahan ribuan koneksi dari aplikasi web dan memetakannya ke sejumlah kecil koneksi permanen (backend multiplexing) ke MySQL, menghemat konsumsi memori server database secara signifikan.
  • Zero Data Loss: Sinkronisasi berbasis Paxos consensus algorithm memastikan setiap transaksi di-commit ke mayoritas node sebelum dinyatakan berhasil.

2. Konsep Inti & Deep Dive Arsitektur

Arsitektur yang kita bangun terdiri dari tiga komponen utama: MySQL Server 8.4 dengan Group Replication, MySQL Shell untuk orkestrasi InnoDB Cluster, dan ProxySQL sebagai lapisan perantara (middleware) antara aplikasi web dan basis data.

Alur Data dan Eksekusi di Bawah Kap (Under the Hood)

  1. Aplikasi Backend (PHP/Go/Node.js) mengirimkan SQL query ke ProxySQL pada port 6033.
  2. ProxySQL Query Processor menganalisis apakah query tersebut bertipe SELECT (baca) atau INSERT/UPDATE/DELETE (tulis).
  3. Write Query diteruskan ke MySQL Node yang berstatus PRIMARY di dalam InnoDB Cluster.
  4. Read Query di-load balance ke node SECONDARY (Read-Only) menggunakan query rules yang telah dikonfigurasi di ProxySQL.
  5. Di dalam InnoDB Cluster, transaksi pada node Primary divalidasi oleh Group Replication Plugin menggunakan protokol konsensus Paxos. Transaksi direplikasi ke seluruh node sekundari secara hampir seketika (virtually synchronous).
+-------------------------------------------------------------+
|                    Aplikasi Web (PHP/Go/Node)               |
+-------------------------------------------------------------+
                               |
                         SQL Traffic (Port 6033)
                               v
+-------------------------------------------------------------+
|                         ProxySQL                            | 
|              (Query Routing & Connection Pooling)           |
+-------------------------------------------------------------+
           /                   |                   \
          /                    |                    \
     (Write)                (Read 1)             (Read 2)
        v                      v                    v
+---------------+      +---------------+    +---------------+
|  MySQL 8.4    |      |  MySQL 8.4    |    |  MySQL 8.4    |
| Node 1 (RW)   |<---->| Node 2 (RO)   |<-->| Node 3 (RO)   |
+---------------+      +---------------+    +---------------+
\___________________________________________________________/
                       InnoDB Cluster
                 (Group Replication - Paxos)

3. Perbandingan Komparatif / Analisis Pendekatan

Berikut adalah analisis komparatif mendalam antara berbagai pendekatan ketersediaan tinggi MySQL untuk membantu Anda memahami trade-off arsitektural:

Parameter Komparasi Asynchronous Replication + Keepalived MySQL Master-Slave Semi-Sync InnoDB Cluster (Group Replication) + ProxySQL
Model Konsistensi Eventual Consistency Semi-Synchronous Strongly Consistent (Paxos)
RTO (Recovery Time) Menit hingga Jam (Manual/Script) Menit (Butuh Orchestrator eksternal) Detik (Otomatis oleh Group Replication)
RPO (Recovery Point) Potensi Data Loss Tinggi Zero Data Loss (pada transaksi terkonfirmasi) Zero Data Loss (Distributed Consensus)
Kompleksitas Setup Rendah Sedang Menengah-Tinggi
Overhead CPU/RAM Sangat Rendah Sedang Tinggi (karena protokol konsensus & heartbeat)
Manajemen Koneksi Langsung ke Database (Raw) Langsung ke Database (Raw) Melalui ProxySQL (Connection Pooling & Multiplexing)
Split-Brain Risk Tinggi Sedang Sangat Rendah (Mayoritas node diperlukan)

[!IMPORTANT] Pemilihan InnoDB Cluster mewajibkan latensi jaringan antar node server basis data berada di bawah 10ms (ideally < 2ms dalam satu zona ketersediaan / Availability Zone yang sama) agar protokol konsensus Paxos tidak mengalami timeout.


4. Prasyarat Sistem & Persiapan Lingkungan

Untuk implementasi di lingkungan produksi enterprise, siapkan 4 unit Virtual Machine (VM) atau Bare Metal Server dengan sistem operasi Ubuntu Server 24.04 LTS atau Debian 12:

  • DB-Node-1: IP 192.168.10.11 (MySQL 8.4)
  • DB-Node-2: IP 192.168.10.12 (MySQL 8.4)
  • DB-Node-3: IP 192.168.10.13 (MySQL 8.4)
  • ProxySQL-Node: IP 192.168.10.20 (ProxySQL)

Spesifikasi Minimum per Node Database:

  • CPU: 4 vCPU / Cores
  • RAM: 8 GB (disarankan 16 GB+)
  • Storage: NVMe SSD dengan IOPS tinggi
  • Jaringan: Internal Private Network 1 Gbps / 10 Gbps

Persiapan Awal (Jalankan di Semua Node DB):

# Update sistem dan instal dependensi dasar
sudo apt update && sudo apt upgrade -y
sudo apt install -y wget curl lsb-release gnupg2 ufw

# Atur hostname yang unik
sudo hostnamectl set-data-hostname db-node-1

# Konfigurasi /etc/hosts untuk resolusi nama internal
echo "192.168.10.11 db-node-1" | sudo tee -a /etc/hosts
echo "192.168.10.12 db-node-2" | sudo tee -a /etc/hosts
echo "192.168.10.13 db-node-3" | sudo tee -a /etc/hosts
echo "192.168.10.20 proxysql-node" | sudo tee -a /etc/hosts

5. Panduan Implementasi Langkah demi Langkah

Langkah 1: Instalasi MySQL 8.4 di Ketiga Node DB

Unduh dan pasang repositori resmi MySQL:

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 Server & Cluster -> mysql-8.4-lts -> Apply

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

Langkah 2: Konfigurasi MySQL (/etc/mysql/mysql.conf.d/mysqld.cnf)

Terapkan konfigurasi berikut pada file /etc/mysql/mysql.conf.d/mysqld.cnf di ketiga node (sesuaikan server_id untuk setiap node: Node 1 = 1, Node 2 = 2, Node 3 = 3):

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

# Pengaturan InnoDB
innodb_buffer_pool_size         = 4G
innodb_flush_log_at_trx_commit  = 1
innodb_file_per_table           = 1
innodb_autoinc_lock_mode        = 2

# Pengaturan Binary Log & Replikasi
gtid_mode                       = ON
enforce_gtid_consistency        = ON
binlog_checksum                 = NONE
log_slave_updates               = ON
master_info_repository          = TABLE
relay_log_info_repository       = TABLE

# Pengaturan Group Replication
plugin_load_add                 = "group_replication.so"
loose_group_replication_group_name = "c1234567-89ab-cdef-0123-456789abcdef"
loose_group_replication_start_on_boot = OFF
loose_group_replication_local_address = "192.168.10.11:33061"
loose_group_replication_group_seeds = "192.168.10.11:33061,192.168.10.12:33061,192.168.10.13:33061"
loose_group_replication_bootstrap_group = OFF
loose_group_replication_single_primary_mode = ON
loose_group_replication_enforce_update_every_where_checks = OFF

[!WARNING] Pastikan parameter loose_group_replication_local_address disesuaikan dengan IP node yang bersangkutan (Node 2: 192.168.10.12:33061, Node 3: 192.168.10.13:33061).

Restart layanan MySQL setelah konfigurasi disimpan:

sudo systemctl restart mysql

Langkah 3: Bootstrap InnoDB Cluster Menggunakan MySQL Shell

Masuk ke MySQL Shell dari db-node-1:

mysqlsh root@localhost --sql

Jalankan perintah SQL untuk menyiapkan akun replikasi dan administrator cluster:

SET SQL_LOG_BIN=0;
CREATE USER 'cluster_admin'@'%' IDENTIFIED BY 'StrongAdminPass123!';
GRANT ALL PRIVILEGES ON *.* TO 'cluster_admin'@'%' WITH GRANT OPTION;
CREATE USER 'mysql_healthcheck'@'%' IDENTIFIED BY 'HealthCheckPass123!';
GRANT SELECT ON performance_schema.* TO 'mysql_healthcheck'@'%';
FLUSH PRIVILEGES;
SET SQL_LOG_BIN=1;

Keluar dari mode SQL dan gunakan JavaScript mode di MySQL Shell untuk membuat kluster:

// Keluar ke JS mode
\js

// Hubungkan ke instance lokal
var cluster = dba.createCluster('prod_db_cluster', {
    localAddress: '192.168.10.11:33061',
    adminUser: 'cluster_admin',
    adminPassword: 'StrongAdminPass123!'
});

// Tambahkan Node 2 dan Node 3 ke dalam kluster
cluster.addInstance('cluster_admin@192.168.10.12:3306', {
    recoveryMethod: 'incremental',
    adminUser: 'cluster_admin',
    adminPassword: 'StrongAdminPass123!'
});

cluster.addInstance('cluster_admin@192.168.10.13:3306', {
    recoveryMethod: 'incremental',
    adminUser: 'cluster_admin',
    adminPassword: 'StrongAdminPass123!'
});

// Periksa status kluster
cluster.status();

Langkah 4: Instalasi dan Konfigurasi ProxySQL

Masuk ke server ProxySQL-Node (192.168.10.20):

wget https://www.proxysql.com/downloads/proxysql-2.8.0/proxysql_2.8.0-ubuntu24_amd64.deb
sudo dpkg -i proxysql_2.8.0-ubuntu24_amd64.deb
sudo systemctl start proxysql

Masuk ke antarmuka administratif ProxySQL:

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

Konfigurasikan backend server di dalam ProxySQL (tabel mysql_servers):

-- Masukkan ketiga node database
INSERT INTO mysql_servers(hostgroup_id, hostname, port, status) VALUES (10, '192.168.10.11', 3306, 'ONLINE');
INSERT INTO mysql_servers(hostgroup_id, hostname, port, status) VALUES (20, '192.168.10.11', 3306, 'ONLINE');
INSERT INTO mysql_servers(hostgroup_id, hostname, port, status) VALUES (20, '192.168.10.12', 3306, 'ONLINE');
INSERT INTO mysql_servers(hostgroup_id, hostname, port, status) VALUES (20, '192.168.10.13', 3306, 'ONLINE');

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

Konfigurasikan kredensial pengguna aplikasi (mysql_users):

INSERT INTO mysql_users(username, password, default_hostgroup) VALUES ('app_user', 'AppUserSecret123!', 10);

LOAD MYSQL USERS TO RUNTIME;
SAVE MYSQL USERS TO DISK;

Konfigurasikan aturan pemisahan query baca/tulis (Query Rules):

-- Arahkan semua query yang diawali dengan SELECT (kecuali SELECT FOR UPDATE) ke hostgroup read-only (20)
INSERT INTO mysql_rules(rule_id, active, match_pattern, destination_hostgroup, apply) 
VALUES (1, 1, '^SELECT.*', 20, 1);

-- Arahkan SELECT dengan FOR UPDATE kembali ke hostgroup write (10)
INSERT INTO mysql_rules(rule_id, active, match_pattern, destination_hostgroup, apply) 
VALUES (2, 1, '^SELECT.*FOR UPDATE$', 10, 1);

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

Aktifkan mekanisma Monitor ProxySQL agar secara otomatis mendeteksi node mana yang berstatus PRIMARY dan SECONDARY:

UPDATE global_variables SET variable_value='mysql_healthcheck' WHERE variable_name='mysql-monitor_username';
UPDATE global_variables SET variable_value='HealthCheckPass123!' WHERE variable_name='mysql-monitor_password';
UPDATE global_variables SET variable_value='3000' WHERE variable_name='mysql-monitor_connect_interval';

LOAD MYSQL VARIABLES TO RUNTIME;
SAVE MYSQL VARIABLES TO DISK;

6. Bedah Kode & Penjelasan Detail Baris Kunci

  • innodb_autoinc_lock_mode = 2: Sangat penting dalam lingkungan Group Replication untuk menghindari penguncian tabel saat melakukan operasi INSERT secara konkuren dari berbagai node.
  • gtid_mode = ON dan enforce_gtid_consistency = ON: Mengaktifkan Global Transaction Identifiers yang memastikan setiap transaksi memiliki identitas unik di seluruh kluster, esensial untuk pemulihan otomatis.
  • hostgroup_id = 10 (Write Hostgroup) dan hostgroup_id = 20 (Read Hostgroup): Memisahkan secara tegas jalur lalu lintas SQL agar beban write terpusat pada satu master sementara read didistribusikan secara merata ke seluruh node sekunder.

7. Skenario Produksi & Studi Kasus Dunia Nyata

Pada platform e-commerce dengan 50.000 concurrent requests per second (RPS), lonjakan traffic pada saat flash sale membebani lapisan basis data secara ekstrem. Dengan konfigurasi ProxySQL connection pooling, koneksi dari backend PHP-FPM dipetakan ulang dari 5.000 koneksi aktif menjadi hanya 20 koneksi fisik konstan ke setiap node MySQL. Hal ini mencegah error Too many connections dan menjaga utilisasi RAM server database tetap stabil di bawah 65%.


8. Common Pitfalls, Anti-Patterns & Solusi

  • Anti-Pattern 1: Mengabaikan Pengaturan sysctl Linux pada Server Database. Dampak: Terjadi batasan file descriptor (nofile) saat jumlah koneksi melonjak. Solusi: Tambahkan fs.file-max = 2097152 di /etc/sysctl.conf dan atur batas nofile di /etc/security/limits.conf.
  • Anti-Pattern 2: Tidak Mengonfigurasi mysql-monitor dengan Benar di ProxySQL. Dampak: ProxySQL tetap mengirimkan write query ke node yang baru saja turun (fail), menghasilkan error aplikasi. Solusi: Gunakan Galera/Group Replication check query bawaan ProxySQL untuk memverifikasi status read-only setiap node secara periodik.

9. Benchmark, Metrik Kinerja & Tuning Performa

Lakukan pengujian beban menggunakan tool sysbench untuk memvalidasi performa kluster:

# Persiapan tabel benchmark
sysbench /usr/share/sysbench/oltp_read_write.lua \
  --mysql-host=192.168.10.20 \
  --mysql-port=6033 \
  --mysql-user=app_user \
  --mysql-password=AppUserSecret123! \
  --table-size=1000000 \
  --tables=10 prepare

# Eksekusi benchmark 5 menit
sysbench /usr/share/sysbench/oltp_read_write.lua \
  --mysql-host=192.168.10.20 \
  --mysql-port=6033 \
  --mysql-user=app_user \
  --mysql-password=AppUserSecret123! \
  --table-size=1000000 \
  --tables=10 \
  --time=300 \
  --threads=64 run

Evaluasi metrik utama: QPS (Queries Per Second), Latency rata-rata (< 5ms), dan Error Rate (harus 0%).


10. Checklist Penerapan Produksi & Kesimpulan

  1. Pastikan sinkronisasi waktu NTP aktif di seluruh node (chrony / ntpd).
  2. Konfigurasi Firewall (UFW/iptables) hanya mengizinkan port 3306, 33061, dan 6033 dari subnet internal aplikasi.
  3. Buat jadwal pencadangan (backup) otomatis menggunakan mysqlbackup atau mydumper/myloader ke penyimpanan S3/MinIO.
  4. Uji skenario pemutusan jaringan (network partition / chaos engineering) secara berkala untuk memverifikasi kecepatan failover otomatis.

Dengan mengintegrasikan MySQL 8.4 InnoDB Cluster dan ProxySQL, Anda telah membangun infrastruktur basis data enterprise yang memiliki ketahanan tinggi, performa optimal, serta skalabilitas yang siap menghadapi lonjakan beban kerja ekstrem di masa depan.

🏷️ Tags: #Mysql #High Availability #Proxysql #Database Architecture #Innodb Cluster