Redis Sentinel ile Yüksek Erişilebilirlik

Redis'i tek bir sunucuda çalıştırıyorsanız, o sunucu düştüğü an uygulamanız da düşer. Bir replika eklemek verinizi korur ama kimse otomatik olarak "artık master bu" demez; birinin uyanıp elle devretme yapması gerekir ve bu, gece üçte on beş dakikalık bir kesinti anlamına gelir. Redis Sentinel tam olarak bu boşluğu doldurur: master'ı sürekli izler, gerçekten çöktüğüne birden fazla gözlemciyle karar verir, replikalardan birini master'a yükseltir ve uygulamanıza yeni adresi bildirir.

Bu rehberde Sentinel'in nasıl çalıştığını, üç Sentinel ve iki replikadan oluşan gerçek bir kurulumu sıfırdan yapmayı, quorum ile majority arasındaki farkı ve neden ikisini de doğru ayarlamanız gerektiğini, devretmeyi elle test etmeyi, uygulama tarafında Sentinel destekli bağlantı kurmayı ve split-brain riskini min-replicas-to-write ile sınırlamayı anlatacağım. Sonda da bu mimariyi kuranların en sık düştüğü tuzakları topladım.

Sentinel Ne Yapar, Cluster'dan Farkı Ne#

Sentinel, veriyi bölmez. Tüm veri tek bir master'da durur ve replikalar onun birebir kopyasını tutar. Sentinel süreçleri veri yolunun dışında durur; hiçbir istek onların üzerinden geçmez. Görevleri üçtür: master ve replikaların sağlığını izlemek, master'ın gerçekten çöktüğüne karar vermek ve yeni master'ı seçip yapılandırmayı güncellemek. Ayrıca uygulamalara "şu an master kim" sorusunun cevabını veren bir keşif servisi olarak da çalışırlar.

Bu, Redis Cluster ile karıştırılmaması gereken bir mimaridir. Cluster veriyi düğümlere böler ve bellek kapasitesini ölçekler; Sentinel yalnızca erişilebilirlik sağlar ve tüm veri hâlâ tek bir makinenin belleğine sığmak zorundadır.

Karar kuralı basittir: veriniz tek makinenin belleğine sığıyorsa ve tek istediğiniz "master çökerse hizmet devam etsin" ise Sentinel doğru cevaptır. Belleğe sığmıyorsa Cluster gerekir.

Master ve Replika Kurulumu#

Sentinel kurmadan önce çalışan bir replikasyon zinciriniz olmalı. Üç sunucu varsayalım: 185.12.34.56 master, 185.12.34.57 ve 185.12.34.58 replika.

Master tarafında yapılandırma sadece dış erişime izin vermek ve parolayı ayarlamaktan ibarettir:

# /etc/redis/redis.conf — master (185.12.34.56)
bind 0.0.0.0 -::1
protected-mode yes
port 6379

requirepass guclu-redis-parolasi
masterauth  guclu-redis-parolasi     # devretme sonrası replika olursa gerekir

appendonly yes
appendfsync everysec

# En az 1 replika bağlı ve gecikmesi 10 saniyeden azsa yazmaya izin ver
min-replicas-to-write 1
min-replicas-max-lag 10

Replikalarda tek fark replicaof satırıdır:

# /etc/redis/redis.conf — replika (185.12.34.57 ve .58)
bind 0.0.0.0 -::1
port 6379

replicaof 185.12.34.56 6379
masterauth  guclu-redis-parolasi
requirepass guclu-redis-parolasi

# Devretme sonrası master olabilmesi için yazmaya kapalı kalması normaldir
replica-read-only yes

masterauth satırını her üç sunucuya da yazmak kritiktir. Devretme sonrası eski master bir replikaya dönüşür ve yeni master'a bağlanmak için bu parolaya ihtiyaç duyar; yoksa sessizce bağlanamaz ve senkronizasyon kopar.

Replikasyonun çalıştığını doğrulayın:

redis-cli -h 185.12.34.56 -a guclu-redis-parolasi INFO replication
# role:master
# connected_slaves:2
# slave0:ip=185.12.34.57,port=6379,state=online,offset=...,lag=0
# slave1:ip=185.12.34.58,port=6379,state=online,offset=...,lag=0

state=online ve lag değerinin küçük olması gerekir. Kalıcılık ayarlarının devretme sırasındaki etkisi için Redis persistence: RDB ve AOF farkı yazısına göz atın.

Sentinel Yapılandırması ve Quorum#

Sentinel'in sayısı tek olmalıdır ve en az üç tane gerekir. Sebep, devretme kararının çoğunluk oyuyla verilmesidir: iki Sentinel ile biri düştüğünde kalan tek süreç çoğunluk oluşturamaz ve devretme yapılamaz. Sentinel'leri Redis düğümlerinin üzerine kurabilirsiniz ama ideal olan, en azından birini ayrı bir makinede tutmaktır.

# /etc/redis/sentinel.conf — her üç Sentinel'de aynı
port 26379
bind 0.0.0.0 -::1
protected-mode no

# İzlenecek master: takma ad, ip, port, quorum
sentinel monitor cloutr-master 185.12.34.56 6379 2

# Master'a bu kadar ms cevap vermezse "subjectively down" say
sentinel down-after-milliseconds cloutr-master 5000

# Devretme bu sürede tamamlanmazsa iptal et
sentinel failover-timeout cloutr-master 60000

# Yeni master'a aynı anda kaç replika senkronize olsun
sentinel parallel-syncs cloutr-master 1

# Redis parolası
sentinel auth-pass cloutr-master guclu-redis-parolasi

# Sentinel'lerin kendi arasındaki kimlik doğrulaması (opsiyonel ama önerilir)
requirepass sentinel-parolasi

dir /var/lib/redis-sentinel
logfile /var/log/redis/sentinel.log

sentinel monitor satırının sonundaki 2 quorum değeridir ve en çok yanlış anlaşılan ayardır. Quorum yalnızca şunu belirler: master'ın çöktüğüne kaç Sentinel'in hemfikir olması gerekiyor. Ancak devretmeyi başlatmak için ayrıca Sentinel'lerin çoğunluğunun hayatta olması gerekir ve bu ikinci koşul quorum'dan bağımsızdır.

Yani quorum'u 1'e çekerek devretmeyi kolaylaştırdığınızı sanmayın; çoğunluk koşulu her zaman geçerlidir ve iki Sentinel'li bir kurulumda biri düştüğünde hiçbir şey olmaz.

Sentinel'leri başlatıp durumu kontrol edin:

sudo systemctl start redis-sentinel

redis-cli -p 26379 -a sentinel-parolasi SENTINEL master cloutr-master
redis-cli -p 26379 -a sentinel-parolasi SENTINEL replicas cloutr-master
redis-cli -p 26379 -a sentinel-parolasi SENTINEL sentinels cloutr-master

Üçüncü komut diğer iki Sentinel'i listelemelidir. Boş dönüyorsa Sentinel'ler birbirini bulamamıştır; 26379 portunun üç sunucu arasında açık olduğunu kontrol edin.

Devretmeyi Test Etmek#

Kurulumu yapıp "çalışıyor herhalde" diye bırakmak en yaygın hatadır. Devretmeyi kurulum günü test edin; gerçek bir arıza anında ilk kez denemek istemezsiniz.

En temiz test, Sentinel'e elle devretme yaptırmaktır. Bu, gerçek bir arıza simüle etmez ama zincirin çalıştığını gösterir:

redis-cli -p 26379 -a sentinel-parolasi SENTINEL failover cloutr-master

# Birkaç saniye sonra yeni master'ı sorun
redis-cli -p 26379 -a sentinel-parolasi SENTINEL get-master-addr-by-name cloutr-master
# 1) "185.12.34.57"
# 2) "6379"

Daha gerçekçi bir test, master'ı bloklayarak cevapsız bırakmaktır. DEBUG SLEEP komutu Redis'i belirtilen süre boyunca tamamen durdurur:

# Master'ı 30 saniye dondur — down-after-milliseconds (5s) aşılır
redis-cli -h 185.12.34.56 -a guclu-redis-parolasi DEBUG SLEEP 30

# Başka bir terminalde Sentinel günlüğünü izleyin
sudo tail -f /var/log/redis/sentinel.log

Günlükte şu sırayı görmelisiniz: +sdown (bu Sentinel master'ı ulaşılamaz gördü), +odown (quorum sağlandı, nesnel olarak çökük), +try-failover, +elected-leader, +switch-master cloutr-master 185.12.34.56 6379 185.12.34.57 6379. Son satır devretmenin tamamlandığını ve yeni master'ın adresini gösterir.

Devretme sonrası eski master ayağa kalktığında Sentinel onu otomatik olarak yeni master'ın replikası yapar ve redis.conf dosyasına replicaof satırını kendisi yazar. Bu yüzden yapılandırma dosyalarınızı sürüm kontrolünden birebir dağıtan bir sisteminiz varsa dikkatli olun: Sentinel'in yazdığı satırı ezerseniz eski master kendini yeniden master ilan eder ve split-brain oluşur.

Uygulama Tarafında Bağlantı#

Sentinel'in bütün faydası, uygulamanızın yeni master'ı otomatik bulabilmesindedir. Bunun için uygulama, Redis'e doğrudan sabit bir IP ile değil, Sentinel üzerinden bağlanmalıdır. Modern Redis istemci kütüphanelerinin hemen hepsinde Sentinel desteği vardır ve yapılandırma şu şekle benzer: Sentinel adreslerinin listesi, master'ın takma adı (cloutr-master) ve parolalar.

İstemci açılışta Sentinel'lerden birine bağlanıp SENTINEL get-master-addr-by-name sorar, dönen adrese bağlanır ve devretme olduğunda Sentinel'in yayınladığı +switch-master mesajına abone olarak bağlantısını yeniler. Bu mekanizmayı elle taklit etmeye çalışmak yerine kütüphanenin Sentinel istemcisini kullanın.

Kütüphane desteği yoksa iki alternatif vardır. Birincisi HAProxy gibi bir katman koyup sağlık kontrolüyle master'ı bulmaktır:

# /etc/haproxy/haproxy.cfg — sadece master'a yönlendiren backend
backend redis_master
    mode tcp
    option tcp-check
    tcp-check send AUTH\ guclu-redis-parolasi\r\n
    tcp-check expect string +OK
    tcp-check send info\ replication\r\n
    tcp-check expect string role:master
    server r1 185.12.34.56:6379 check inter 2s
    server r2 185.12.34.57:6379 check inter 2s backup
    server r3 185.12.34.58:6379 check inter 2s backup

İkincisi, Sentinel'in client-reconfig-script kancasıyla devretme anında bir betik çalıştırıp DNS kaydını veya sanal IP'yi güncellemektir. Her iki yaklaşımda da ek bir bileşen devreye girer; mümkünse istemci kütüphanesinin yerleşik desteğini tercih edin.

Split-Brain Riski ve Sık Yapılan Hatalar#

Split-brain, ağ bölünmesi sonucu iki düğümün de kendini master sanmasıdır. Senaryo şudur: master ile Sentinel çoğunluğu arasındaki ağ kopar, Sentinel'ler devretme yapıp bir replikayı yükseltir, ama eski master hâlâ çalışıyor ve kendi tarafındaki istemcilerden yazma kabul ediyordur. Bölünme düzeldiğinde eski master replika olur ve o süre içinde aldığı yazmalar kaybolur.

Bu riski tamamen ortadan kaldıramazsınız ama pencereyi daraltabilirsiniz. Master tarafındaki iki ayar tam olarak bunun içindir:

# Bağlı ve güncel en az 1 replika yoksa yazma kabul etme
min-replicas-to-write 1
min-replicas-max-lag 10

Bu ayarlarla, çoğunluktan kopmuş bir master replikalarını da kaybettiği anda yazmayı reddeder ve kaybedilecek veri en fazla min-replicas-max-lag saniyelik olur. Bedeli şudur: replikalarınız gerçekten düştüğünde master da yazma kabul etmez. Erişilebilirlik ile tutarlılık arasındaki bu değiş tokuşu bilinçli yapın.

Diğer sık hatalar şunlar:

Sentinel sayısını çift tutmak. İki veya dört Sentinel, çoğunluk hesabını bozar. Daima tek sayı kullanın: 3 veya 5.

Tüm Sentinel'leri Redis düğümleriyle aynı makinelere koymak. Bir veri merkezi ya da bir hypervisor arızası hem Redis'i hem Sentinel çoğunluğunu birlikte götürürse devretme yapacak kimse kalmaz. En az bir Sentinel'i ayrı bir makinede tutun.

masterauth satırını unutmak. Devretme sonrası eski master replikaya dönüşür ve parola olmadan yeni master'a bağlanamaz. Sorun sessizdir; INFO replication çıktısında master_link_status:down görene kadar fark edilmez.

26379 portunu güvenlik duvarında açmamak. Sentinel'ler birbirini bu port üzerinden bulur. Kapalıysa her Sentinel kendini yalnız sanar ve çoğunluk hiç oluşmaz.

Devretmeyi hiç test etmemek. Kurulumun ardından mutlaka bir kez elle devretme yapın, günlükleri okuyun ve uygulamanızın yeni master'a geçtiğini doğrulayın. Test edilmemiş bir HA kurulumu, HA kurulumu değildir.

down-after-milliseconds değerini çok küçük tutmak. 1000 ms gibi bir değer, kısa bir ağ dalgalanmasında gereksiz devretme tetikler. Her devretme bir kesinti ve olası veri kaybı demektir; 5000 ms makul bir başlangıçtır.

Sıkça Sorulan Sorular#

Kaç tane Sentinel kurmalıyım#

En az üç, ve daima tek sayı. Devretme kararı için Sentinel'lerin çoğunluğunun hayatta olması gerekir; üç Sentinel ile bir tanesini kaybetmeyi tolere edersiniz, beş ile iki tanesini. İki Sentinel kurmak işe yaramaz çünkü biri düştüğünde kalan tek süreç çoğunluk oluşturamaz ve devretme hiç yapılamaz. Sentinel'ler hafif süreçlerdir, kaynak tüketimleri ihmal edilebilir.

Quorum değerini kaç yapmalıyım#

Standart öneri, Sentinel sayısının çoğunluğuna eşitlemektir: üç Sentinel için 2, beş için 3. Quorum yalnızca "master çöktü" kararının kaç oyla verileceğini belirler; devretmeyi başlatmak için ayrıca çoğunluğun hayatta olması şarttır ve bu koşulu quorum'u düşürerek atlayamazsınız. Quorum'u gereğinden küçük yapmak, geçici ağ sorunlarında gereksiz devretmeleri kolaylaştırır.

Devretme ne kadar sürer#

Tipik bir kurulumda birkaç saniyedir. Süre üç bileşenden oluşur: down-after-milliseconds boyunca master'ın cevapsız kalması, Sentinel'lerin lider seçimi ve yeni master'ın yükseltilip replikaların ona yönlendirilmesi. Varsayılan 5 saniyelik down-after-milliseconds ile toplam süre genelde 6-10 saniye arasında kalır. Bu sürede uygulamanız yazma yapamaz, dolayısıyla istemci tarafında yeniden deneme mantığı bulunmalıdır.

Sentinel veri kaybını tamamen önler mi#

Hayır. Redis replikasyonu asenkrondur; master bir yazmayı kabul edip replikaya iletmeden çökerse o yazma kaybolur. Sentinel bu davranışı değiştirmez, yalnızca hizmetin devam etmesini sağlar. Kaybı sınırlamak için min-replicas-to-write ve min-replicas-max-lag ayarlarını kullanabilir, kalıcılık tarafında AOF everysec çalıştırabilirsiniz; ama sıfır kayıp garantisi Redis'in mimarisinde yoktur.

Uygulamam Sentinel'i desteklemiyorsa ne yapmalıyım#

İki pratik yol var. Birincisi HAProxy gibi bir TCP yük dengeleyici koyup role:master sağlık kontrolüyle her zaman master'a yönlendirmesini sağlamaktır; uygulama sabit bir adrese bağlanır ve devretmeden habersiz kalır. İkincisi Sentinel'in client-reconfig-script kancasıyla devretme anında DNS kaydını veya sanal IP'yi güncelleyen bir betik çalıştırmaktır. İlk seçenek daha hızlı tepki verir, ikincisi ek bileşen gerektirmez ama DNS önbelleği yüzünden gecikmeli olabilir.

Sentinel ile Cluster'ı birlikte kullanabilir miyim#

Hayır ve gerek de yok. Redis Cluster kendi devretme mekanizmasını içerir; master'ların çoğunluğu bir düğümün çöktüğüne karar verir ve replikasını yükseltir. Cluster üzerine ayrıca Sentinel kurmak hem gereksizdir hem de iki mekanizmanın çakışmasına yol açar. Karar noktası şudur: bellek ölçekleme gerekiyorsa Cluster, yalnızca erişilebilirlik gerekiyorsa Sentinel.

Kapanış#

Redis Sentinel, doğru kurulduğunda gece üçteki telefonları ortadan kaldıran sade bir mekanizmadır. Aklınızda tutmanız gerekenler şunlar: Sentinel sayısını tek ve en az üç yapın, en az birini Redis düğümlerinden farklı bir makinede tutun, masterauth satırını üç sunucuya da yazın çünkü devretme sonrası eski master ona ihtiyaç duyar ve kurulumu bitirir bitirmez elle bir devretme testi yapın. Split-brain penceresini daraltmak için min-replicas-to-write ayarını da bilinçli olarak seçin.

Bu mimari en az üç sunucu ister ve düğümler arasındaki gecikme devretme süresini doğrudan etkiler. Aynı altyapıda hızla çoğaltabileceğiniz bulut sunucu veya VDS paketlerimiz bu topoloji için uygun bir taban sağlar; yüksek erişilebilirlik hedefinizi ölçmek için uptime SLA hesaplayıcı aracımızı kullanabilirsiniz. Kurulum, izleme ve düzenli devretme provalarını devretmek isterseniz sunucu yönetimi hizmetimiz bu döngüyü sizin adınıza işletir.