# Mencapai High Availability 99.99% pada Klaster Database MySQL & Redis

> Diterbitkan oleh Literally Web ID pada 21 Oct 2026
> Sumber: https://literally.web.id/articles/mencapai-high-availability-9999-pada-klaster-database-mysql-redis

---

Pernahkah kamu terbangun jam 3 pagi karena pagerduty berteriak kencang, mendapati database MySQL utama kita mendadak *read-only* akibat jaringan kedip, sementara Redis caching layer ikut amblas karena memory fragmentation? Rasanya seperti berdiri di atas jembatan gantung yang talinya putus satu-persatu. Di level 99.99% availability—yang membatasi waktu *downtime* tahunan kita hanya sekitar 52 menit total—kita tidak bisa lagi mengandalkan doa atau sekadar me-restart service secara manual. Kita butuh benteng pertahanan terdistribusi yang otonom. Mari kita bedah bagaimana merancang arsitektur MySQL Group Replication dan Redis Sentinel agar klaster bisa menyembuhkan dirinya sendiri tanpa campur tangan manusia.

Perjalanan kita dimulai dari bagaimana mendesain fondasi paling krusial dalam ekosistem penyimpanan data web modern, yang sering kali menjadi penentu apakah infrastruktur kita bertahan atau justru tumbang saat trafik melonjak tajam.

## 1. Intisari Kilat: Fondasi dalam Sekali Lirik

> [!IMPORTANT]
> Angka 99.99% bukanlah hasil dari satu komponen yang sempurna, melainkan eliminasi *single point of failure* (SPOF) di setiap lapisan: DNS Cloudflare, Load Balancer Nginx, hingga inti database dan RAM Redis.

Dalam dunia arsitektur skala besar, catatan tempel mental kita harus selalu ringkas: MySQL Group Replication (MGR) bekerja secara multi-master atau single-master berbasisPaxos, menjamin konsistensi data kuat (*strong consistency*) antar node lewat *group communication engine*. Sementara itu, Redis Sentinel bertindak sebagai pengawas eksternal yang memantau kesehatan *master-replica*, siap melakukan *auto-failover* dalam hitungan detik ketika *master* terdeteksi *down*. 

Ketika kedua teknologi ini dipadukan dengan backend PHP-FPM atau Node.js yang menerapkan *connection pooling* cerdas, serta dilindungi WAF dan Fail2ban di gerbang depan, kita mendapatkan ekosistem yang tahan banting. Namun, pertanyaannya sekarang: kapan kita harus memilih arsitektur ini dibandingkan opsi replikasi asinkron tradisional?

## 2. Kompas Keputusan: Kapan Memilih Solusi Ini vs Alternatif Lain

Jika beban kerja aplikasimu didominasi oleh transaksi finansial atau sistem e-commerce di mana *dirty read* adalah dosa besar, langsung pilih MySQL Group Replication (MGR) mode *multi-primary* atau *single-primary* dengan *consistency level* diatur ke `BEFORE_AND_AFTER`. Hindari replikasi *async* standar karena lag beberapa detik saja bisa membuat pengguna melakukan *double spend* atau *overselling* stok barang.

> [!TIP]
> Untuk Redis, jika datasetmu masih muat di dalam RAM satu mesin fisik besar, jangan langsung pakai Redis Cluster yang kompleks. Gunakan **Redis Master-Replica dengan Redis Sentinel**. Redis Cluster hanya wajib jika kebutuhan RAM-mu melampaui kapasitas satu server (misal > 64GB) dan kamu butuh *sharding* data.

Mari kita intip parameter apa saja yang harus kita setel di dalam file konfigurasi agar klaster ini benar-benar kebal terhadap anomali jaringan.

## 3. Contekan Konfigurasi & Parameter Paling Sering Dicari

Berikut adalah konfigurasi `my.cnf` untuk MySQL Group Replication yang sudah teruji di medan perang produksi berbeban tinggi:

```ini
[mysqld]
# Identitas Server Unik
server-id = 1
port = 3306

# Pengaturan InnoDB untuk Performa Tinggi
innodb_buffer_pool_size = 12G
innodb_flush_log_at_trx_commit = 1
innodb_file_per_table = 1

# Konfigurasi Wajib Group Replication
gtid_mode = ON
enforce_gtid_consistency = ON
master_info_repository = TABLE
relay_log_info_repository = TABLE
binary_log_checksum = NONE
log_slave_updates = ON
gtid-executed-compression-period = 1000

# Plugin Group Replication
plugin-load-add=group_replication.so
group_replication_group_name="10a28394-7164-11ee-8c99-0242ac120002"
group_replication_start_on_boot = OFF
group_replication_local_address = "192.168.1.10:33061"
group_replication_group_seeds = "192.168.1.10:33061,192.168.1.11:33061,192.168.1.12:33061"
group_replication_bootstrap_group = OFF
group_replication_single_primary_mode = ON
group_replication_enforce_update_every_where_checks = OFF
```

Sementara itu, untuk sisi Redis Sentinel, pastikan konfigurasi `sentinel.conf` di tiga node terpisah dikonfigurasi seperti ini agar tidak mudah terjebak oleh *false positive* akibat lonjakan latensi sesaat:

```conf
port 26379
daemonize yes
pidfile /var/run/redis-sentinel.pid
logfile "/var/log/redis/sentinel.log"

# Pantau Master Redis pada IP lokal dengan kuorum 2 dari 3 sentinel
sentinel monitor mymaster 192.168.1.50 6379 2

# Jika master tidak merespons dalam 5 detik, anggap down (default 30 detik terlalu lama)
sentinel down-after-milliseconds mymaster 5000

# Batas waktu failover sebelum dibatalkan
sentinel failover-timeout mymaster 60000

# Jumlah replika yang boleh re-configure secara paralel saat failover
sentinel parallel-syncs mymaster 1
```

Konfigurasi di atas tidak akan ada artinya jika kita tidak memegang kendali penuh di terminal saat situasi darurat melanda.

## 4. Koleksi Mantra One-Iner Siap Salin untuk Keseharian

Simpan baris-baris perintah terminal ini di catatan harianmu sebagai SRE:

```bash
# 1. Cek status kesehatan MySQL Group Replication secara real-time via SQL
mysql -u root -p -e "SELECT * FROM performance_schema.replication_group_members;"

# 2. Bootstrapping MGR pertama kali dari node utama
mysql -u root -p -e "SET GLOBAL group_replication_bootstrap_group=ON; START GROUP_REPLICATION; SET GLOBAL group_replication_bootstrap_group=OFF;"

# 3. Cek status Redis Sentinel quorum dan master aktif dari CLI
redis-cli -p 26379 sentinel masters

# 4. Paksa Redis Sentinel melakukan failover manual (Switch-over darurat)
redis-cli -p 26379 sentinel failover mymaster

# 5. Cek fragmentasi memori Redis yang sering bikin OOM killer beraksi
redis-cli info memory | grep mem_fragmentation_ratio
```

Tapi ingat, kekuatan besar datang bersama potensi bencana yang besar pula. Satu kesalahan konfigurasi kecil dapat memicu skenario terburuk yang mengancam seluruh data perusahaan.

## 5. Jalur Bahaya: Dosa Besar yang Wajib Dihindari di Produksi

> [!WARNING]
> **Jangan pernah** mengatur jumlah node Group Replication atau Redis Sentinel menjadi bilangan genap (misal: 2 atau 4 node). Algoritma konsensus (Paxos/Raft) membutuhkan kuorum mayoritas ($N/2 + 1$) untuk mencegah skenario *split-brain*. Jika klaster beranggotakan 2 node dan jaringan terbelah dua (*network partition*), kedua node akan merasa dirinya adalah penguasa sah, menerima tulis secara bersamaan, dan menghasilkan korupsi data permanen yang mustahil digabungkan kembali.

Dosa besar kedua adalah mengabaikan parameter `down-after-milliseconds` pada Redis Sentinel terlalu rendah di lingkungan cloud (AWS/GCP) yang rentan terhadap fluktuasi jaringan mikro, yang berakibat pada *flapping failover* terus-menerus. Selalu uji ketahanan infrastrukturmu dengan menyimulasikan pemutusan kabel jaringan (*chaos engineering*) sebelum benar-benar merilis sistem ini ke tangan jutaan pengguna di luar sana.