Redis çoğu kurumda “cache” diye başlar, sonra sessizce kritik state taşımaya başlar: rate limit sayaçları, idempotency store, session, feature flag vb. Bu noktada “tek node Redis” bir teknik borç değil, direkt incident tetikleyicisidir.
Sentinel, Redis için pratik bir HA yaklaşımı sunar; ama en tehlikeli failure mode şudur: split-brain (iki farklı master oluşması veya yanlış master’a yazılması).
Bu yazı, Sentinel kurulumunu değil; Sentinel kullanan bir sistemin operasyonel runbook’unu anlatır.
1) Ön koşul: HA tasarımının minimum standardı
Minimum güvenli başlangıç:
- 1 master + 1 replica (tercihen 2 replica)
- En az 3 Sentinel (farklı failure domain)
Sentinel tarafında hedef: master’ı “ölü” kabul etme ve yeni master seçme kararını tek bir node’un gözlemine bırakmamak.
2) Triage: “Redis mi gitti, yoksa failover mı oldu?”
Semptomlar:
- Cache miss artışı, latency spike
- “READONLY You can’t write against a read only replica” hatası
- Uygulama connection error / timeout
2.1 Rol doğrulama
Master/replica rolünü hızlı doğrula:
redis-cli -h <redis-host> -p 6379 INFO replication | rg -n \"role|master_host|master_link_status|connected_slaves\" -SBeklenen:
- master:
role:master - replica:
role:slave+master_link_status:up
2.2 Sentinel gözünden durum
redis-cli -h <sentinel-host> -p 26379 SENTINEL masters
redis-cli -h <sentinel-host> -p 26379 SENTINEL slaves <master-name>
redis-cli -h <sentinel-host> -p 26379 SENTINEL get-master-addr-by-name <master-name>Amaç:
- Sentinel “master kim?” sorusuna tutarlı cevap veriyor mu?
- Farklı Sentinel’lar farklı master gösteriyor mu? (split-brain şüphesi)
3) Split-brain nasıl anlaşılır?
Split-brain’in saha sinyalleri:
- İki farklı node aynı anda
role:masterdiyebilir - Sentinel’lar farklı master adresi döndürür
- Yazma başarısızlıkları “read-only replica” ve “MOVED/ASK” gibi karma davranışlarla karışır
- Cache “tutarsız” görünür (bazı kullanıcılar logged-in, bazıları değil)
4) Incident müdahalesi: adım adım
4.1 Önce yazmayı stabilize et (yükü ve hasarı durdur)
Hedef: yanlış master’a yazmayı azaltmak.
Pratik seçenekler:
- Uygulamada Redis yazma path’ini geçici kısıtla (feature flag / degrade)
- Cache’i “read-only moda” çek (mümkünse)
- Trafiği azalt (rate limit / shed load)
4.2 “Doğru master” kararını ver
Karar kriterleri:
- En güncel replika kim? (replication lag / offset)
- Hangi node daha uzun süredir master? (failover zamanı)
- Uygulama hangi node’a yazdı? (log/metric)
Operasyonel kural: “En az veri kaybı” öncelik olmalı. Cache bile olsa, bazı cache verileri güvenlik kararını etkileyebilir.
4.3 Yanlış master’ı yazmaya kapat
Eğer bir node yanlışlıkla master olduysa, onu “replica” davranışına geri çekmek gerekebilir.
Örnek yaklaşım (dikkat: saha koşuluna göre değişir):
# yanlış master'ı doğru master'a replika yap (yanlış yönde ise veri kaybı yaşanabilir)
redis-cli -h <wrong-master> -p 6379 REPLICAOF <correct-master-ip> 6379Bu adımı uygulamadan önce:
- Trafiği düşür
- Mümkünse snapshot al (RDB/AOF)
- Veri kaybı etkisini kabul ettir (incident komutası)
5) Kalıcı korumalar: split-brain riskini küçült
5.1 Yazma güvenliği: “min-replicas” koruması
Redis tarafında, master’ın replika görmeden yazma kabul etmesini engelleyebilirsin:
min-replicas-to-write 1
min-replicas-max-lag 10Saha yorumu:
- Replika yoksa veya lag çoksa master yazmayı reddeder → kısa süreli hata üretir ama split-brain hasarını azaltır.
5.2 Sentinel parametrelerini “gerçek”e göre ayarla
Üç kritik parametre:
down-after-millisecondsfailover-timeoutquorum
Yanlış ayar örnekleri:
- Çok düşük
down-after: kısa network jitter’da gereksiz failover - Çok agresif failover: flap ve tutarsız master
5.3 Tatbikat: failover testi yapmadan güven olmaz
Ayda bir küçük tatbikat bile fark yaratır:
- master’ı kontrollü kapat → failover süresi ölç
- ağ bölünmesi simülasyonu (staging) → quorum davranışı gözle
- uygulama tarafında retry/timeouts “failover’ı büyütüyor mu?” kontrol et
6) Runbook kapanış: doğrulama
Stabilite doğrulaması:
- Tek bir master kaldı mı?
- Sentinel’ların tamamı aynı master’ı gösteriyor mu?
- Uygulama hata oranı normale döndü mü?
Redis Sentinel, doğru kurulduğunda operasyonu rahatlatır; yanlış kurulduğunda ise “otomatik failover” adı altında incident üretir. Buradaki fark, teknolojiden çok operasyon disiplinidir: quorum, tatbikat ve kanıtlı runbook.