Bilgi Bankası
RedisOlay ve bakım 13 dk 14.06.2026

Redis Cluster mı Sentinel mi: yüksek erişilebilirlik beklentisi nasıl kurulmalı?

Redis tarafında Sentinel ve Cluster çoğu zaman aynı şeymiş gibi konuşulur. Oysa Sentinel esas olarak failover düzenidir; Cluster ise veriyi parçalara dağıtan farklı bir mimaridir. Doğru seçim, “kaç GB veri var?” kadar “uygulama istemcisi neyi destekliyor?” sorusuna da bağlıdır.

Bu yazı sana şu durumda yardımcı olur
  • Redis tek node çalışıyor ve kesinti riski var
  • Sentinel mi Cluster mı seçileceği karışık
  • uygulama istemcisinin Cluster destekleyip desteklemediği bilinmiyor
  • failover olunca bağlantıların nasıl toparlanacağı test edilmedi
  • cache ile kalıcı veri beklentisi birbirine karışıyor
Yazıyı bitirince

Redis Sentinel ve Cluster arasındaki farkı, hangi durumda hangisinin anlamlı olduğunu ve HA beklentisini nasıl test etmeniz gerektiğini netleştireceksiniz.

TürkDB açısından ürünleşme notu

Bu bölüm, TürkDB’nin ilgili problemi hangi ürün ilkeleri ve kontrol noktalarıyla ele alacağını anlatır. Kapsam, gerçek iş yükü ve ihtiyaçla birlikte netleşir.

TürkDB Redis için bağlantı, kapasite, olay ve yedekleme görünürlüğünü sadeleştirmeyi hedefler. Sentinel veya Cluster seçimi ise iş yükü, veri boyutu, istemci desteği ve kabul edilebilir veri kaybı riskiyle birlikte değerlendirilmelidir.

Sentinel ve Cluster aynı problem değildir

Redis Sentinel, primary düştüğünde replikanın devralmasını koordine eder. Ama veriyi shardlara bölmez. Veri tek primary hattında büyür, replika ise yüksek erişilebilirlik için durur.

Redis Cluster ise veriyi hash slotlar üzerinden birden fazla primary node’a dağıtır. Bu kapasite ve yatay ölçekleme sağlar; ama uygulama istemcisinin cluster yönlendirmelerini doğru anlaması gerekir.

  • Sentinel: failover ve izleme için anlamlıdır.
  • Cluster: sharding ve daha büyük veri hacmi için anlamlıdır.
  • Cluster kullanıyorsanız istemci MOVED/ASK yönlendirmelerini desteklemelidir.
  • İki modelde de failover testi yapılmadan üretim güveni oluşmaz.

Cache mi, kalıcı iş durumu mu?

Redis yalnızca cache ise kısa süreli veri kaybı kabul edilebilir olabilir; uygulama kaynak veriden yeniden üretir. Ama Redis oturum, kuyruk, idempotency veya sayaç gibi iş açısından kritik veri taşıyorsa HA kararı daha ciddi hale gelir.

Sentinel veya Cluster seçimi yapmadan önce Redis’in sistemdeki rolünü yazın. “Kaybolursa yeniden üretiriz” ile “kaybolursa kullanıcı etkilenir” aynı mimari değildir.

Redis rol sınıflandırması

redis-role-matrix.md
Key grubu:
Amaç: cache / oturum / kuyruk / sayaç / kilit
Kaynak gerçeklik nerede:
Kaybolursa yeniden üretilebilir mi:
Kabul edilebilir kesinti:
Kabul edilebilir veri kaybı:
Sentinel mi Cluster mı daha uygun:

Failover testi istemciyle birlikte yapılır

Redis tarafında node değişimi başarılı olsa bile uygulama bağlantıyı toparlayamıyorsa kullanıcı kesinti yaşar. Bu yüzden test yalnızca Redis loguna bakarak bitmez; uygulama pool davranışı, retry mantığı ve hata mesajları da izlenir.

Özellikle Cluster kullanıyorsanız istemcinin slot haritasını yenileyip yenilemediği kontrol edilmelidir. Bazı eski veya yanlış yapılandırılmış istemciler failover sonrası aynı node’a istek göndermeye devam eder.

HA, veri kaybı yok demek değildir

Redis replikasyonu asenkron olabilir. Primary düştüğü anda replikanın son yazıları alıp almadığı garanti olmayabilir. Bu nedenle yüksek erişilebilirlik ile sıfır veri kaybı aynı cümle değildir.

Kritik yazılar için Redis yerine kalıcı veritabanı, outbox veya başka dayanıklı mekanizma gerekebilir. Redis hızlıdır; ama hız, her veri türü için tek başına doğru cevap değildir.

Devam etmek istersen

Sorunu motor bazında derinleştirin

Benzer belirtiler farklı motorlarda farklı nedenlere dayanır; yayınlanan tüm rehberleri ana sayfadan takip edebilirsiniz.

Tüm makaleler