Belajar Redis - Troubleshooting & Operational Maintenance

#Pendahuluan

Semua sistem produksi akan bermasalah — yang membedakan engineer profesional adalah kesiapan. Episode 19 ini membekali kalian troubleshooting masalah Redis yang paling umum dan maintenance rutin yang mencegahnya terjadi lagi.

Kita akan membedah empat keluhan klasik — high latency spikes, OOM command not allowed, connection exhaustion, dan replication disconnect — lalu menjadwalkan backup, melakukan upgrade tanpa downtime, dan menyiapkan prosedur disaster recovery. Ini materi yang paling dicari saat di pager.

#Troubleshooting Masalah Umum

#High Latency Spikes

Spike latency mendadak hampir selalu berakar pada operasi background yang memanfaatkan fork:

• RDB snapshot (save berkala) melakukan fork yang menyalin page table memori.
• AOF rewrite yang panjang.
• Perintah BGSAVE/BGREWRITEAOF yang dipicu manual saat beban tinggi.

Cara pertama memastikan: cek LATENCY LATEST untuk event fork:

redis-cli LATENCY LATEST
redis-cli INFO stats | grep latest_fork_usec

LATENCY LATEST menampilkan event fork jika ada — latest_fork_usec mengungkap berapa lama fork berlangsung. Mitigasi: jadwalkan snapshot di jam sepi, naikkan save interval, dan gunakan activedefrag hati-hati agar tidak bentrok.

#Memory Full: OOM Command Not Allowed

Error OOM command not allowed when used memory > 'maxmemory' berarti maxmemory tercapai dan policy noeviction sedang aktif (atau eviction tidak berhasil menurunkan memori):

redis-cli INFO memory | grep -E "used_memory|maxmemory"
redis-cli CONFIG GET maxmemory-policy

Langkahnya: pastikan policy bukan noeviction untuk workload cache, perbesar maxmemory jika server masih punya RAM cadangan, dan audit key boros dengan MEMORY USAGE. Untuk jangka panjang, pertimbangkan sharding (episode 13).

#Client Connection Exhaustion

Error max number of clients reached menandakan maxclients tercapai — sering karena connection leak di aplikasi (episode 16) atau pool terlalu kecil:

redis-cli INFO clients
redis-cli CONFIG GET maxclients

connected_clients yang terus naik walau traffic datar = leak. Fix sisi aplikasi (pakai pool, tutup koneksi) lebih baik daripada menaikkan maxclients yang justru membebani memori dan CPU.

#Replication Disconnect & Full Resync

Replica yang bolak-balik disconnect memicu full resync berulang — menguras bandwidth dan memori master:

redis-cli INFO replication
redis-cli INFO stats | grep total_sync

master_link_status:up menandakan sehat. total_sync yang bertambah cepat menandakan resync berulang — biasanya karena timeout atau buffer repl backlog terlalu kecil. Naikkan repl-backlog-size dan periksa jaringan antara master-replica.

#Operational Maintenance

#Menjadwalkan Backup

Snapshot dan rewrite sebaiknya dijadwalkan, bukan menunggu trigger otomatis yang bisa bentrok dengan jam sibuk:

redis-cli BGSAVE
redis-cli BGREWRITEAOF

BGSAVE membuat snapshot RDB di background; BGREWRITEAOF menulis ulang AOF agar ringkas. Jadwalkan keduanya di luar jam puncak dan tidak bersamaan — fork bertumpuk adalah resep spike latency. Di production, backup file .rdb ke storage eksternal setiap hari sebagai jaring pengaman.

#Rolling Upgrade tanpa Downtime

Untuk upgrade Redis di arsitektur Sentinel atau Cluster, lakukan node demi node agar service tidak pernah mati total:

1. upgrade replica (tidak melayani trafik)
2. pindahkan trafik / promote replica → master baru
3. upgrade master lama (kini replica) dan kembalikan topologi

Di Sentinel: upgrade replica terlebih dahulu, lalu lakukan SENTINEL FAILOVER untuk mempromosikan replica yang sudah di-upgrade, dan upgrade node sisanya. Di Cluster, patuh pada urutan yang sama — selalu upgrade yang tidak melayani trafik lebih dulu.

#Disaster Recovery

#Restore dari RDB Snapshot

Saat instance hancur dan harus dibangun ulang dari backup:

redis-cli --rdb /tmp/backup.rdb
redis-cli SHUTDOWN

Langkahnya: stop server, taruh file .rdb dengan nama sesuai dbfilename di direktori dir, lalu start. Untuk AOF, cukup taruh file AOF (Redis 7 menggunakan format multi-part di direktori appenddirname) — pastikan restore AOF tidak berjalan bersamaan dengan snapshot yang basi. Selalu verifikasi DBSIZE setelah restore.

#Recovery Cluster saat Majority Masters Down

Ketika banyak master di cluster mati sekaligus, cluster-require-full-coverage (default yes) membuat cluster menolak seluruh query karena ada slot tanpa pemilik:

redis-cli -p 7000 CLUSTER INFO
redis-cli -p 7000 CLUSTER NODES

Strateginya: aktifkan replicas yang tersisa (CLUSTER FAILOVER), nyalakan kembali node yang mati, dan biarkan resharding memulihkan distribusi. Jika replica tidak cukup, nilai risiko cluster-require-full-coverage no — trade-off availability vs. data consistency — dan segera tambah node. Prosedur recovery harus ditulis, diuji, dan disimulasikan sebelum insiden sungguhan.

#Penutup

Episode 19 membekali kalian sisi operasional Redis: menangani high latency spikes dari fork, error OOM, connection exhaustion, dan replication disconnect; menjadwalkan BGSAVE/BGREWRITEAOF; rolling upgrade; serta prosedur restore RDB dan recovery cluster.

Inti yang harus dibawa pulang:

• Spike latency hampir selalu berasal dari fork — cek LATENCY LATEST dan latest_fork_usec.
• OOM command not allowed berarti maxmemory tercapai dengan policy noeviction.
• max number of clients reached biasanya connection leak di aplikasi, bukan server.
• Replication disconnect berulang menandakan backlog repl terlalu kecil atau jaringan buruk.
• Jadwalkan BGSAVE/BGREWRITEAOF di luar jam puncak dan jangan bersamaan.
• Rolling upgrade: selalu upgrade yang tidak melayani trafik lebih dulu.
• Restore RDB: stop server, letakkan .rdb, start, verifikasi DBSIZE.
• DR procedure wajib diuji dengan failover drill rutin.

Di episode 20 selanjutnya — episode terakhir series ini — kita merangkai semuanya dalam studi kasus arsitektur Redis production-grade: caching layer dengan Cache-Aside, session store, rate limiting, real-time features, leaderboard, semuanya di atas 6-node cluster dengan TLS, ACL, dan monitoring. Mari kita rancang arsitektur lengkapnya!