Redis Sentinel ile Yüksek Erişilebilirlik Kurulumu

yazar

Production ortamında Redis kullanıyorsanız, tek bir Redis instance’ı ile çalışmak ciddi riskler barındırır. O sunucu çöktüğünde uygulamanız da çöker, veriler kaybolabilir ve müşterileriniz bundan nasibini alır. Redis Sentinel tam da bu noktada devreye girer: otomatik failover, izleme ve bildirim mekanizmalarıyla Redis’inizi 7/24 ayakta tutar. Bu yazıda gerçek bir production senaryosu üzerinden Redis Sentinel kurulumunu adım adım ele alacağız.

Redis Sentinel Nedir ve Neden Gereklidir?

Redis Sentinel, Redis için dağıtık bir yüksek erişilebilirlik çözümüdür. Üç temel görevi vardır: izleme (master ve slave node’ları sürekli kontrol eder), bildirim (bir şeyler ters gittiğinde API veya sistem yöneticisine haber verir) ve otomatik failover (master düştüğünde bir slave’i otomatik olarak master’a terfi ettirir).

Sentinel’in en güzel yanı, uygulamanızın Redis adresini Sentinel’e sormasıdır. Sentinel de size o an hangi sunucunun master olduğunu söyler. Failover gerçekleştiğinde uygulama yeni master’ı otomatik olarak öğrenir, siz saatlerce hata ayıklamak zorunda kalmazsınız.

Tipik bir Sentinel topolojisi şöyle görünür:

  • 1 Redis Master: Yazma işlemleri buraya gelir
  • 2 Redis Slave: Master’dan veri replike eder, okuma işlemleri buraya yönlendirilebilir
  • 3 Sentinel Node: Birbirleriyle koordineli çalışır, quorum kararı alır

Sentinel node sayısının neden önemli olduğunu anlamak için quorum kavramını kavramak gerekir. Quorum, bir master’ın “dead” sayılması için kaç Sentinel’in aynı fikirde olması gerektiğini belirler. 3 Sentinel ile quorum genellikle 2 olarak ayarlanır. Bu sayede split-brain senaryolarının önüne geçilir.

Lab Ortamı ve Sunucu Yapısı

Bu yazıda kullandığımız ortam:

  • redis-master: 192.168.1.10 – Ubuntu 22.04
  • redis-slave-1: 192.168.1.11 – Ubuntu 22.04
  • redis-slave-2: 192.168.1.12 – Ubuntu 22.04
  • Sentinel’ler her üç sunucuda da çalışacak
  • Redis sürümü: 7.x

Gerçek hayatta Sentinel node’larını uygulama sunucularına da koyabilirsiniz. Önemli olan quorum sayısına ulaşabilmek.

Redis Kurulumu

Her üç sunucuya da Redis kurulumu yapılır. Önce paket reposunu ekleyelim:

# Her üç sunucuda çalıştırın
sudo apt update
sudo apt install -y lsb-release curl gpg

curl -fsSL https://packages.redis.io/gpg | sudo gpg --dearmor -o /usr/share/keyrings/redis-archive-keyring.gpg

echo "deb [signed-by=/usr/share/keyrings/redis-archive-keyring.gpg] https://packages.redis.io/deb $(lsb_release -cs) main" | sudo tee /etc/apt/sources.list.d/redis.list

sudo apt update
sudo apt install -y redis-server redis-sentinel

Kurulum sonrası servis durumunu kontrol edin:

sudo systemctl status redis-server
sudo systemctl status redis-sentinel

Master Sunucu Konfigürasyonu

Master sunucuda /etc/redis/redis.conf dosyasını düzenleyelim:

sudo nano /etc/redis/redis.conf

Aşağıdaki parametreleri bulup güncelleyin veya ekleyin:

# Tüm interface'lerde dinle (veya sadece gerekli IP'lerde)
bind 0.0.0.0

# Port
port 6379

# Daemonize
daemonize yes

# Log dosyası
logfile /var/log/redis/redis-server.log

# Veri dizini
dir /var/lib/redis

# Şifre belirle (production'da mutlaka kullanın)
requirepass "GucluBirSifre2024!"

# Master olarak slave bağlantılarını doğrula
masterauth "GucluBirSifre2024!"

# AOF aktif et (veri dayanıklılığı için)
appendonly yes
appendfilename "appendonly.aof"

# RDB snapshot
save 900 1
save 300 10
save 60 10000

# Maksimum bellek (sunucunuza göre ayarlayın)
maxmemory 2gb
maxmemory-policy allkeys-lru

# TCP keepalive
tcp-keepalive 300

Konfigürasyonu kaydettikten sonra servisi yeniden başlatın:

sudo systemctl restart redis-server
sudo systemctl enable redis-server

Slave Sunucu Konfigürasyonu

Her iki slave sunucuda da benzer konfigürasyon yapılır, tek fark replicaof direktifidir:

# redis-slave-1 ve redis-slave-2 için /etc/redis/redis.conf

bind 0.0.0.0
port 6379
daemonize yes
logfile /var/log/redis/redis-server.log
dir /var/lib/redis

# Bu satır slave'i master'a bağlar
replicaof 192.168.1.10 6379

# Master şifresi (master requirepass ile aynı olmalı)
masterauth "GucluBirSifre2024!"

# Slave'in kendi şifresi
requirepass "GucluBirSifre2024!"

# Slave sadece okuma yapsın
replica-read-only yes

# AOF
appendonly yes

# Bellek
maxmemory 2gb
maxmemory-policy allkeys-lru

Her iki slave’de de servisi başlatın:

sudo systemctl restart redis-server
sudo systemctl enable redis-server

Replikasyon Doğrulaması

Master’da replikasyonun çalıştığını doğrulayalım:

redis-cli -a "GucluBirSifre2024!" info replication

Çıktıda şunu görmelisiniz:

# Replication
role:master
connected_slaves:2
slave0:ip=192.168.1.11,port=6379,state=online,offset=1234,lag=0
slave1:ip=192.168.1.12,port=6379,state=online,offset=1234,lag=0
master_failover_state:no-failover
master_replid:a1b2c3d4e5f6...

İki slave’in state=online olduğunu gördüğünüzde replikasyon sağlıklı çalışıyor demektir.

Sentinel Konfigürasyonu

Şimdi asıl iş başlıyor. Her üç sunucuda da Sentinel’i yapılandıracağız. /etc/redis/sentinel.conf dosyasını düzenleyin:

sudo nano /etc/redis/sentinel.conf

Her üç sunucu için aynı konfigürasyon kullanılabilir:

# Sentinel port
port 26379

# Daemonize
daemonize yes

# Log
logfile /var/log/redis/sentinel.log

# Çalışma dizini
dir /tmp

# Master izleme tanımı
# sentinel monitor <master-adı> <ip> <port> <quorum>
sentinel monitor mymaster 192.168.1.10 6379 2

# Master şifresi
sentinel auth-pass mymaster "GucluBirSifre2024!"

# Master kaç ms yanıt vermezse down sayılsın?
sentinel down-after-milliseconds mymaster 5000

# Failover timeout (ms)
sentinel failover-timeout mymaster 60000

# Failover sırasında kaç slave aynı anda sync yapsın?
sentinel parallel-syncs mymaster 1

# Sentinel kendi şifresi (Redis 6.2+)
sentinel sentinel-pass "SentinelSifresi2024!"

# Bildirim scripti (opsiyonel ama önerilir)
# sentinel notification-script mymaster /var/redis/notify.sh

# Announce IP (NAT arkasındaysa önemli)
sentinel announce-ip 192.168.1.10  # Her sunucuda kendi IP'si olacak
sentinel announce-port 26379

Önemli not: sentinel announce-ip satırını her sunucuda o sunucunun kendi IP’siyle güncelleyin. redis-slave-1’de 192.168.1.11, redis-slave-2’de 192.168.1.12 olmalıdır.

Sentinel’i başlatın:

sudo systemctl restart redis-sentinel
sudo systemctl enable redis-sentinel

Sentinel Doğrulaması

Sentinel’in master’ı tanıyıp tanımadığını kontrol edelim:

redis-cli -p 26379 -a "SentinelSifresi2024!" sentinel master mymaster

Çıktıda master bilgileri ve slave sayısı görünmeli:

 1) "name"
 2) "mymaster"
 3) "ip"
 4) "192.168.1.10"
 5) "port"
 6) "6379"
...
19) "num-slaves"
20) "2"
21) "num-other-sentinels"
22) "2"

Slave’leri görmek için:

redis-cli -p 26379 -a "SentinelSifresi2024!" sentinel slaves mymaster

Diğer Sentinel’leri görmek için:

redis-cli -p 26379 -a "SentinelSifresi2024!" sentinel sentinels mymaster

Firewall Kuralları

UFW kullanıyorsanız gerekli portları açın:

# Redis portunu yalnızca kendi subnet'inden kabul et
sudo ufw allow from 192.168.1.0/24 to any port 6379
sudo ufw allow from 192.168.1.0/24 to any port 26379

# Uygulamalar için (uygulama sunucularının IP bloğuna göre ayarlayın)
sudo ufw allow from 192.168.2.0/24 to any port 6379
sudo ufw allow from 192.168.2.0/24 to any port 26379

sudo ufw reload

Failover Testi

Kurulumun gerçekten çalışıp çalışmadığını test etmeden production’a almayın. Bilerek master’ı çökertelim:

# Master sunucuda Redis'i durdurun
sudo systemctl stop redis-server

# Başka bir terminalde Sentinel logunu izleyin
tail -f /var/log/redis/sentinel.log

Sentinel logunda şuna benzer çıktı görmelisiniz:

+sdown master mymaster 192.168.1.10 6379
+odown master mymaster 192.168.1.10 6379 #quorum 2/2
+new-epoch 1
+try-failover master mymaster 192.168.1.10 6379
+vote-for-leader <sentinel-id> 1
+elected-leader master mymaster 192.168.1.10 6379
+failover-state-select-slave master mymaster 192.168.1.10 6379
+selected-slave slave 192.168.1.11:6379 192.168.1.11 6379 @ mymaster 192.168.1.10 6379
+failover-state-send-slaveof-noone slave 192.168.1.11:6379 192.168.1.11 6379 @ mymaster 192.168.1.10 6379
+failover-state-wait-promotion slave 192.168.1.11:6379 192.168.1.11 6379 @ mymaster 192.168.1.10 6379
+promoted-slave slave 192.168.1.11:6379 192.168.1.11 6379 @ mymaster 192.168.1.10 6379
+failover-state-reconf-slaves master mymaster 192.168.1.10 6379
+slave-reconf-sent slave 192.168.1.12:6379 192.168.1.12 6379 @ mymaster 192.168.1.10 6379
+failover-end master mymaster 192.168.1.10 6379
+switch-master mymaster 192.168.1.10 6379 192.168.1.11 6379

Artık yeni master 192.168.1.11. Doğrulayalım:

redis-cli -p 26379 sentinel get-master-addr-by-name mymaster

Eski master’ı geri getirdiğinizde bu sefer slave olarak devreye girecek:

sudo systemctl start redis-server
# Birkaç saniye bekleyin, sonra:
redis-cli -p 26379 sentinel slaves mymaster

Uygulama Tarafı Entegrasyonu

Uygulamanızın Sentinel ile konuşabilmesi için doğru konfigürasyon şarttır. Python örneği:

# Python ile redis-py sentinel kullanımı
pip install redis
from redis.sentinel import Sentinel

sentinel = Sentinel(
    [
        ('192.168.1.10', 26379),
        ('192.168.1.11', 26379),
        ('192.168.1.12', 26379),
    ],
    sentinel_kwargs={'password': 'SentinelSifresi2024!'},
    socket_timeout=0.5
)

# Master bağlantısı (yazma için)
master = sentinel.master_for(
    'mymaster',
    socket_timeout=0.5,
    password='GucluBirSifre2024!'
)

# Slave bağlantısı (okuma için)
slave = sentinel.slave_for(
    'mymaster',
    socket_timeout=0.5,
    password='GucluBirSifre2024!'
)

# Kullanım
master.set('anahtar', 'deger')
deger = slave.get('anahtar')
print(deger)

Node.js için ioredis paketi de Sentinel desteği sunar:

const Redis = require('ioredis');

const redis = new Redis({
  sentinels: [
    { host: '192.168.1.10', port: 26379 },
    { host: '192.168.1.11', port: 26379 },
    { host: '192.168.1.12', port: 26379 }
  ],
  name: 'mymaster',
  sentinelPassword: 'SentinelSifresi2024!',
  password: 'GucluBirSifre2024!',
  role: 'master' // veya 'slave' okuma için
});

redis.set('test', 'merhaba');
redis.get('test').then(console.log);

İzleme ve Alerting

Prometheus ve Grafana kullanıyorsanız redis_exporter ile metrikleri toplayabilirsiniz:

# redis_exporter kurulumu
wget https://github.com/oliver006/redis_exporter/releases/download/v1.55.0/redis_exporter-v1.55.0.linux-amd64.tar.gz
tar xzf redis_exporter-v1.55.0.linux-amd64.tar.gz
sudo mv redis_exporter /usr/local/bin/

# Servis olarak başlatmak için
sudo tee /etc/systemd/system/redis-exporter.service > /dev/null <<EOF
[Unit]
Description=Redis Exporter
After=network.target

[Service]
User=redis
ExecStart=/usr/local/bin/redis_exporter 
  --redis.addr=redis://192.168.1.10:6379 
  --redis.password=GucluBirSifre2024! 
  --web.listen-address=:9121

Restart=always

[Install]
WantedBy=multi-user.target
EOF

sudo systemctl daemon-reload
sudo systemctl enable --now redis-exporter

Dikkat etmeniz gereken başlıca metrikler:

  • redis_up: Sunucu ayakta mı?
  • redis_connected_slaves: Kaç slave bağlı?
  • redis_replication_lag: Replikasyon gecikmesi kaç saniye?
  • redis_memory_used_bytes: Bellek kullanımı
  • redis_keyspace_hits_total / redis_keyspace_misses_total: Cache hit oranı

Sık Karşılaşılan Sorunlar

Sentinel Birbirini Görmüyor

num-other-sentinels değeri beklediğinizden azsa:

  • Firewall kurallarını kontrol edin (port 26379)
  • sentinel announce-ip doğru IP’yi gösteriyor mu?
  • sentinel.conf dosyasının her Sentinel tarafından yazılabilir olduğundan emin olun (Sentinel runtime’da bu dosyayı günceller)

Split-Brain Senaryosu

Ağ bölünmesi durumunda iki Sentinel aynı anda farklı master seçebilir. Bunu önlemek için:

  • Quorum değerini doğru ayarlayın (3 Sentinel için quorum 2)
  • min-replicas-to-write parametresi ile master’ın yazma kabul etmesini slave sayısına bağlayın:
# Master konfigürasyonuna ekleyin
min-replicas-to-write 1
min-replicas-max-lag 10

Bu ayarla en az 1 slave bağlıysa ve lag 10 saniyenin altındaysa master yazma kabul eder. Slave sayısı 0’a düşerse yazma reddedilir, bu da split-brain durumunda eski master’ın “izole” kalmasını sağlar.

Failover Çok Uzun Sürüyor

down-after-milliseconds değeriniz çok yüksekse failover geç başlar. Production ortamlarında 5000ms (5 saniye) genellikle makul bir değerdir. Çok agresif olmak da tehlikelidir; geçici ağ sorunları gereksiz failover tetikleyebilir.

Yedekleme Stratejisi

Sentinel yüksek erişilebilirlik sağlar ama yedeklemenin yerini tutmaz. RDB yedeklerini düzenli alın:

#!/bin/bash
# /opt/scripts/redis-backup.sh

BACKUP_DIR="/backup/redis"
DATE=$(date +%Y%m%d_%H%M%S)
REDIS_AUTH="GucluBirSifre2024!"

mkdir -p $BACKUP_DIR

# BGSAVE ile RDB oluştur
redis-cli -a $REDIS_AUTH BGSAVE

# BGSAVE tamamlanana kadar bekle
while [ $(redis-cli -a $REDIS_AUTH LASTSAVE) -eq $(redis-cli -a $REDIS_AUTH LASTSAVE) ]; do
    sleep 1
done

# RDB dosyasını kopyala
cp /var/lib/redis/dump.rdb $BACKUP_DIR/dump_$DATE.rdb

# 7 günden eski yedekleri sil
find $BACKUP_DIR -name "dump_*.rdb" -mtime +7 -delete

echo "Yedekleme tamamlandi: dump_$DATE.rdb"

Cron’a ekleyin:

# Her gece 02:00'de çalıştır
0 2 * * * /opt/scripts/redis-backup.sh >> /var/log/redis-backup.log 2>&1

Sonuç

Redis Sentinel kurulumu ilk bakışta karmaşık görünse de adımları doğru takip ettiğinizde oldukça sağlam bir yüksek erişilebilirlik altyapısı elde edersiniz. Bu yazıda ele aldığımız konuları özetleyelim:

  • 1 master + 2 slave replikasyon topolojisi kurulumu
  • 3 Sentinel node ile quorum tabanlı otomatik failover
  • Firewall konfigürasyonu ve güvenlik
  • Uygulama entegrasyonu (Python ve Node.js)
  • Prometheus ile izleme
  • Split-brain koruması
  • Yedekleme stratejisi

Sentinel, Redis Cluster kadar karmaşık değildir ve yüzlerce GB verisi olmayan, çok sayıda shard gerektirmeyen çoğu uygulama için idealdir. Eğer veri setiniz tek sunucuya sığıyor ve yatay ölçekleme ihtiyacınız yoksa Sentinel tam size göre.

Son olarak şunu vurgulayayım: Failover testini production’a almadan yapın. Staging ortamında master’ı bilerek çökertip uygulamanızın ne kadar sürede yeni master’a bağlandığını ölçün. Bu süre sizin RTO (Recovery Time Objective) hedefinizle örtüşüyor mu? Örtüşmüyorsa down-after-milliseconds ve failover-timeout değerlerini buna göre ayarlayın. İyi çalışmalar.

Yorum yapın