Strategi High Availability & Disaster Recovery pada Klaster Redis & MySQL

1. Konteks Industri & Analisis Akar Masalah

Dalam lanskap arsitektur sistem modern berbasis web, ketersediaan tinggi (High Availability / HA) dan pemulihan bencana (Disaster Recovery / DR) bukan lagi sekadar fitur tambahan (nice-to-have), melainkan fondasi mutlak. Kegagalan basis data atau caching layer dapat melumpuhkan seluruh ekosistem bisnis dalam hitungan detik. Sebagai Infrastructure Architect, saya sering menemui skenario di mana sistem backend (PHP, Go, Node.js) dibangun dengan sangat skalabel menggunakan container orchestrator seperti Kubernetes, namun mengabaikan titik kegagalan tunggal (Single Point of Failure / SPOF) pada lapisan persistensi data seperti MySQL dan Redis.

Secara historis, kegagalan infrastruktur basis data sering disebabkan oleh split-brain syndrome, kegagalan replikasi asinkron, atau proses failover manual yang memakan waktu (Recovery Time Objective / RTO yang tinggi). Sebelum penerapan klaster berbasis replikasi otomatis, downtime akibat gangguan jaringan atau kegagalan perangkat keras memakan waktu rata-rata 30 hingga 60 menit untuk mitigasi manual. Hal ini berakibat fatal pada hilangnya pendapatan, rusaknya integritas data, dan buruknya pengalaman pengguna akhir.

Dengan menerapkan arsitektur MySQL Group Replication (MGR) yang dipadukan dengan Redis Sentinel atau Redis Cluster, serta dihubungkan melalui HAProxy dan Keepalived untuk manajemen Virtual IP (VIP), kita dapat memangkas RTO hingga mendekati nol (zero-downtime failover) dan memastikan Recovery Point Objective (RPO) mendekati nol pada MySQL berkat mode Multi-Master Group Replication.

2. Konsep Inti & Deep Dive Arsitektur

Arsitektur tahan banting ini mengandalkan integrasi empat komponen utama: MySQL Group Replication untuk konsistensi data relasional, Redis Sentinel untuk pengawasan dan failover otomatis layanan cache, HAProxy sebagai load balancer cerdas yang mendeteksi kesehatan node, serta Keepalived untuk memastikan ketersediaan IP publik/lokal (Virtual IP) bagi aplikasi backend.

+-----------------------------------------------------------------------+
|                         APPLICATION LAYER                             |
|                  (PHP-FPM / Go / Node.js Backend)                     |
+-----------------------------------------------------------------------+
                                   |
                                   v
+-----------------------------------------------------------------------+
|                   HIGH AVAILABILITY ENTRYPOINT                        |
|                 [Keepalived VIP: 192.168.1.100]                       |
|                                  |                                    |
|                                  v                                    |
|                     [HAProxy Load Balancer]                           |
+-----------------------------------------------------------------------+
           |                                           |
           v (Port 3306)                               v (Port 6379)
+-----------------------+                   +---------------------------+
| MySQL GROUP REPL      |                   | REDIS SENTINEL / CLUSTER  |
| [Node 1] [Node 2]     |                   | [Master] [Replica 1]      |
| [Node 3] (MGR Engine) |                   | [Replica 2] [Sentinel]    |
+-----------------------+                   +---------------------------+

Alur Kerja di Balik Layar:

1. MySQL Group Replication: Menggunakan arsitektur berbasis Paxos untuk memastikan transaksi divalidasi dan diterapkan secara konsisten di seluruh node. Jika node primer mati, algoritma konsensus memilih primer baru secara otomatis tanpa intervensi manual.
2. Redis Sentinel: Memantau instans Redis Master dan Replica. Jika Master tidak merespons dalam waktu down-after-milliseconds, Sentinel melakukan quorum voting dan mempromosikan Replica terbaik menjadi Master baru.
3. HAProxy & Keepalived: Keepalived memastikan satu IP virtual mengalir ke HAProxy aktif. HAProxy melakukan health check berkala ke port MySQL dan Redis. Jika terjadi kegagalan pada node primer, HAProxy secara dinamis merutekan lalu lintas ke node sekunder yang telah dipromosikan.

3. Perbandingan Komparatif / Analisis Pendekatan

Berikut adalah analisis mendalam mengenai pendekatan arsitektur HA untuk MySQL dan Redis.

4. Prasyarat Sistem & Persiapan Lingkungan

Sebelum memulai implementasi teknis, pastikan lingkungan infrastruktur memenuhi spesifikasi minimum berikut:

• Sistem Operasi: Ubuntu Server 22.04 LTS (Minimal 3 Node untuk kuorum: node1, node2, node3).
• Spesifikasi Hardware per Node: 4 vCPU, 8 GB RAM, 50 GB NVMe SSD.
• Jaringan: IP statis lokal, pastikan port berikut terbuka di firewall (ufw / iptables):
  • MySQL: 3306 (Client), 33061 (Group Replication)
  • Redis: 6379 (Data), 26379 (Sentinel)
  • Keepalived: VRRP Protocol
• Paket Dependensi: mysql-server, redis-server, haproxy, keepalived.

[!IMPORTANT] Pastikan sinkronisasi waktu NTP (Network Time Protocol) aktif di seluruh node klaster (chrony atau systemd-timesyncd). Perbedaan waktu antar node dapat menyebabkan kegagalan konsensus Paxos pada MySQL Group Replication.

5. Panduan Implementasi Langkah demi Langkah

Langkah 1: Konfigurasi MySQL Group Replication (MGR)

Edit file konfigurasi MySQL /etc/mysql/mysql.conf.d/mysqld.cnf pada ketiga node (Sesuaikan IP untuk setiap node):

[mysqld]
server-id                 = 1
port                      = 3306
bind-address              = 0.0.0.0

# Replication Configuration
gtid_mode                 = ON
enforce_gtid_consistency  = ON
master_info_repository    = TABLE
relay_log_info_repository = TABLE
binary_log_compression    = ON
log_slave_updates         = ON
binlog_checksum           = NONE

# Group Replication Configuration
plugin_load_add           = "group_replication.so"
group_replication_group_name = "1a2b3c4d-5e6f-7a8b-9c0d-1e2f3a4b5c6d"
group_replication_start_on_boot = OFF
group_replication_local_address = "192.168.1.11:33061"
group_replication_group_seeds = "192.168.1.11:33061,192.168.1.12:33061,192.168.1.13:33061"
group_replication_bootstrap_group = OFF
group_replication_single_primary_mode = ON
group_replication_enforce_update_every_where_checks = OFF

Jalankan perintah SQL berikut pada Node 1 untuk melakukan bootstrap klaster:

SET GLOBAL group_replication_bootstrap_group=ON;
START GROUP_REPLICATION;
SET GLOBAL group_replication_bootstrap_group=OFF;

Jalankan pada Node 2 dan Node 3 untuk bergabung ke klaster:

START GROUP_REPLICATION;

Verifikasi status MGR:

SELECT * FROM performance_schema.replication_group_members;

Langkah 2: Konfigurasi Redis Sentinel

Konfigurasi master Redis pada /etc/redis/redis.conf:

bind 0.0.0.0
port 6379
protected-mode no
requirepass "StrongRedisPassword2026!"
masterauth "StrongRedisPassword2026!"
appendonly yes
appendfsync everysec

Konfigurasi Redis Sentinel pada /etc/redis/sentinel.conf di ketiga node:

port 26379
sentinel monitor mymaster 192.168.1.11 6379 2
sentinel down-after-milliseconds mymaster 5000
sentinel failover-timeout mymaster 60000
sentinel auth-pass mymaster "StrongRedisPassword2026!"
sentinel parallel-syncs mymaster 1

Jalankan layanan Redis dan Sentinel:

systemctl restart redis-server
systemctl enable redis-server

Langkah 3: Konfigurasi HAProxy

Edit /etc/haproxy/haproxy.cfg untuk mengatur load balancing MySQL dan Redis:

global
    log /dev/log local0
    log /dev/log local1 notice
    chroot /var/lib/haproxy
    user haproxy
    group haproxy
    daemon
    maxconn 4096

defaults
    log global
    mode tcp
    option tcplog
    option dontlognull
    retries 3
    timeout queue 1m
    timeout connect 10s
    timeout client 30m
    timeout server 30m

frontend mysql_front
    bind 192.168.1.100:3306
    mode tcp
    default_backend mysql_back

backend mysql_back
    mode tcp
    balance roundrobin
    option httpchk SELECT 1
    default-server inter 3s fall 3 rise 2
    server mysql-node1 192.168.1.11:3306 check port 3306
    server mysql-node2 192.168.1.12:3306 check port 3306
    server mysql-node3 192.168.1.13:3306 check port 3306

frontend redis_front
    bind 192.168.1.100:6379
    mode tcp
    default_backend redis_back

backend redis_back
    mode tcp
    balance first
    option tcp-check
    tcp-check send PING\r\n
    tcp-check expect string +PONG
    server redis-node1 192.168.1.11:6379 check inter 2s rise 2 fall 3
    server redis-node2 192.168.1.12:6379 check inter 2s rise 2 fall 3
    server redis-node3 192.168.1.13:6379 check inter 2s rise 2 fall 3

Langkah 4: Konfigurasi Keepalived (High Availability Load Balancer)

Konfigurasi /etc/keepalived/keepalived.conf pada Master Load Balancer:

vrrp_script check_haproxy {
    script "/usr/bin/killall -0 haproxy"
    interval 2
    weight 2
}

vrrp_instance VI_1 {
    state MASTER
    interface eth0
    virtual_router_id 51
    priority 100
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass SecureVRRPPassword!
    }
    virtual_ipaddress {
        192.168.1.100/24
    }
    track_script {
        check_haproxy
    }
}

Pada Backup Load Balancer, ubah state menjadi BACKUP dan priority menjadi 90. Jalankan Keepalived:

systemctl restart keepalived
systemctl enable keepalived

6. Bedah Kode & Penjelasan Detail Baris Kunci

Mari kita bedah beberapa konfigurasi paling kritikal di atas:

• group_replication_single_primary_mode = ON: Menjamin bahwa hanya ada satu node yang menerima operasi tulis (write) dalam satu waktu. Ini mencegah konflik transaksi paralel yang sering terjadi pada mode multi-master, sehingga integritas data relasional tetap terjaga.
• gtid_mode = ON & enforce_gtid_consistency = ON: Menggunakan Global Transaction Identifiers. Setiap transaksi diberi ID unik di seluruh klaster, memudahkan proses pemulihan dan memastikan replikasi berjalan akurat tanpa kehilangan jejak transaksi.
• sentinel monitor mymaster ... 2: Angka 2 di akhir adalah quorum. Artinya, minimal 2 dari 3 Sentinel harus sepakat bahwa Master utama sedang down sebelum proses failover otomatis dipicu. Ini mencegah split-brain akibat gangguan jaringan parsial.
• option httpchk SELECT 1 pada HAProxy: Menguji kesehatan node MySQL dengan mengeksekusi query ringan SELECT 1. Jika node tidak merespons, HAProxy otomatis mengeluarkan node tersebut dari rotasi load balancing.

7. Skenario Produksi & Studi Kasus Dunia Nyata

Dalam sistem e-commerce berskala besar dengan flash sale (misalnya 100.000 requests per second), beban tulis dialirkan melalui VIP 192.168.1.100:3306 ke MySQL MGR, sementara sesi pengguna dan antrean keranjang belanja (shopping cart) dikelola oleh Redis Cluster.

Ketika mysql-node1 mengalami kegagalan hardware mendadak (kernel panic), MGR secara otomatis memilih mysql-node2 sebagai primary baru dalam kurun waktu kurang dari 3 detik. HAProxy mendeteksi kegagalan port 3306 pada node 1 dan mengalihkan koneksi baru ke node 2. Aplikasi backend yang menggunakan connection pooling (seperti PHP-FPM atau Go routine pool) mendeteksi pemutusan koneksi, melakukan reconnect otomatis, dan sistem tetap berjalan tanpa kehilangan data transaksi yang sudah committed.

8. Common Pitfalls, Anti-Patterns & Solusi

[!WARNING] Anti-Pattern Umum: Menggunakan replikasi asinkron standar untuk data finansial tanpa memvalidasi status commit transaksi. Solusi: Selalu aktifkan sync_binlog = 1 pada MySQL dan pastikan innodb_flush_log_at_trx_commit = 1 untuk menjamin data benar-benar tersimpan ke disk (durability ACID).

1. Mengabaikan Pengaturan net_retry_count dan connect_timeout: Kegagalan jaringan sementara sering memutus koneksi replikasi secara permanen jika parameter ini terlalu ketat. Atur nilai timeout yang wajar agar klaster dapat pulih sendiri setelah jaringan stabil.
2. Kurangnya Pemantauan (Monitoring): Gagal memantau ukuran replication lag. Gunakan Prometheus dan Grafana dengan exporter resmi MySQL dan Redis untuk melacak metrik seperti slave_lag_seconds dan redis_connected_slaves.

9. Benchmark, Metrik Kinerja & Tuning Performa

Untuk menguji ketahanan klaster, lakukan pengujian beban menggunakan sysbench untuk MySQL dan redis-benchmark untuk Redis melalui HAProxy VIP:

# Benchmark MySQL via HAProxy VIP
sysbench /usr/share/sysbench/oltp_read_write.lua \
  --mysql-host=192.168.1.100 \
  --mysql-port=3306 \
  --mysql-user=bench_user \
  --mysql-password=SecurePassword \
  --mysql-db=testdb \
  --threads=64 \
  --time=60 run

# Benchmark Redis via HAProxy VIP
redis-benchmark -h 192.168.1.100 -p 6379 -a "StrongRedisPassword2026!" -t set,get -n 100000 -c 50 -P 16

Parameter Tuning Lanjutan (/etc/sysctl.conf):

# Mengoptimalkan penggunaan jaringan dan koneksi TCP
net.core.somaxconn = 65535
net.ipv4.tcp_max_syn_backlog = 65535
net.ipv4.ip_local_port_range = 1024 65535
net.ipv4.tcp_tw_reuse = 1

10. Checklist Penerapan Produksi & Kesimpulan

Sebelum meluncurkan arsitektur ini ke lingkungan produksi penuh, pastikan checklist berikut terpenuhi:

• Seluruh node MySQL dan Redis memiliki sinkronisasi waktu NTP yang akurat.
• Pengujian failover manual dan otomatis telah dilakukan (simulasi pemutusan kabel jaringan / hard reset node primer).
• Konfigurasi firewall dan SELinux/AppArmor telah disesuaikan agar tidak memblokir port internal klaster.
• Strategi backup otomatis (seperti mysqldump / xtrabackup dan Redis RDB snapshot) berjalan secara berkala ke penyimpanan eksternal (S3/MinIO).
• Sistem alerting (PagerDuty / Webhook Telegram) aktif untuk mendeteksi perubahan status node Sentinel dan Keepalived.

Dengan menerapkan panduan komprehensif ini, Anda telah membangun infrastruktur basis data dan caching yang tangguh, siap menghadapi lonjakan trafik ekstrem, serta menjamin kelangsungan operasional bisnis dengan tingkat ketersediaan 99.999%.