Belajar Redis - Replication (Master-Replica) & Redis Sentinel

#Pendahuluan

Sejauh ini kalian mengelola satu instance Redis. Tapi aplikasi produksi butuh lebih: data harus bertahan saat satu node mati, dan beban baca harus bisa disebar. Episode 12 ini menjawab keduanya dengan replication dan Redis Sentinel.

Replication memberi kalian salinan data (replica) untuk read scaling dan backup. Sentinel menambah otomatisasi: jika master mati, Sentinel mempromosikan salah satu replica menjadi master baru tanpa campur tangan manusia. Ini fondasi high availability sebelum melangkah ke Redis Cluster di episode 13.

#Redis Replication

#Konsep Master-Replica

Replication adalah penyalinan data secara asinkron dari satu master (read/write) ke satu atau lebih replicas (read-only). Aplikasi menulis ke master; replica mengikuti perubahan secara terus-menerus. Manfaatnya ganda: read scaling (replica menangani beban baca) dan keamanan data (salinan selalu siap).

            ┌────────────┐
aplikasi ──>│   master   │──> replica 1 (read-only)
            └────────────┘──> replica 2 (read-only)

#Menghubungkan Replica dengan REPLICAOF

Satu baris konfigurasi menghubungkan replica ke master:

redis-cli REPLICAOF 192.168.1.10 6379
redis-cli INFO replication

redis-cli REPLICAOF 192.168.1.10 6379 membuat instance saat ini menjadi replica dari master di 192.168.1.10:6379. INFO replication menampilkan peran (role:slave atau role:master) dan status sinkronisasi. Untuk mengembalikan ke master mandiri, gunakan REPLICAOF NO ONE.

Saat pertama terhubung, replica melakukan full resync: master mengambil snapshot RDB dan mengirimkannya ke replica, lalu mengalirkan perubahan berikutnya. Setelah itu perubahan mengalir terus-menerus (incremental sync).

#Read Scaling

Karena replica read-only, aplikasi bisa mengarahkan query baca ke replica dan menulis hanya ke master:

redis-cli -p 6380 ROLE

redis-cli -p 6380 ROLE menampilkan peran node port 6380. Aturan penting: replica menolak perintah write — SET di replica akan error READONLY. Beban baca yang berat didistribusikan, sementara master fokus melayani write.

#Redis Sentinel

#Sentinel sebagai Watchdog

Sentinel adalah proses terpisah yang memantau master dan replica: memeriksa kesehatan mereka, melaporkan status, dan — yang terpenting — melakukan automatic failover. Sentinel memakai gossip protocol dan voting antar sesama Sentinel untuk menghindari false positive: failover hanya terjadi jika mayoritas Sentinel setuju master bermasalah.

         Sentinel A ──┐
         Sentinel B ──┼── memantau master & replicas
         Sentinel C ──┘
              │ master down
              ▼
         promote replica → master baru

#Automatic Failover

Ketika master dianggap mati oleh mayoritas Sentinel, urutan ini terjadi otomatis:

1. Sentinel menetapkan master tidak sehat (setelah down-after-milliseconds dan quorum tercapai).
2. Sentinel memilih replica terbaik (yang paling sinkron) dan mempromosikannya via REPLICAOF NO ONE.
3. Replica lain diarahkan ke master baru.
4. Aplikasi diarahkan (via Sentinel) untuk memakai master baru.

#Menyiapkan Sentinel

Sentinel berjalan sebagai daemon terpisah dengan file konfigurasi:

sentinel monitor mymaster 192.168.1.10 6379 2
sentinel down-after-milliseconds mymaster 5000
sentinel failover-timeout mymaster 10000
sentinel parallel-syncs mymaster 1

sentinel monitor mymaster 192.168.1.10 6379 2 memberitahu Sentinel untuk memantau master bernama mymaster, dengan quorum 2 (dibutuhkan 2 dari 3 Sentinel untuk menetapkan failover). Jalankan dengan:

redis-server sentinel.conf --sentinel

redis-server sentinel.conf --sentinel memulai Sentinel dalam mode sentinel. Untuk toleransi yang benar, deploy minimal 3 Sentinel di host terpisah — dengan quorum 2, satu Sentinel mati tidak menghentikan failover.

#Aplikasi Terhubung ke Sentinel

Aplikasi tidak perlu hardcode alamat master. Library Redis modern mendukung koneksi via Sentinel: berikan daftar alamat Sentinel dan nama master, dan library otomatis menemukan master aktif — saat failover terjadi, aplikasi ikut beralih tanpa restart.

#Penutup

Episode 12 membekali kalian replication untuk read scaling dan Sentinel untuk high availability: REPLICAOF untuk menghubungkan replica, INFO replication untuk verifikasi, lalu Sentinel dengan sentinel monitor dan automatic failover saat master down.

Inti yang harus dibawa pulang:

• Replication asinkron: master melayani write, replica melayani read.
• REPLICAOF <ip> <port> mengubah node menjadi replica; REPLICAOF NO ONE mengembalikannya.
• Replica menolak write — aplikasi wajib memisahkan jalur baca dan tulis.
• Sentinel memonitor master dan melakukan automatic failover.
• Failover butuh mayoritas Sentinel — deploy minimal 3 instance.
• Library Redis modern bisa memakai Sentinel sebagai service discovery.

Di episode 13 selanjutnya kita membahas Redis Cluster — horizontal scalability dengan sharding otomatis ke 16.384 hash slots. Kalian akan belajar kapan butuh cluster, setup 6 node, dan hash tags untuk multi-key operations. Ini tingkat tertinggi arsitektur Redis!