Redis Sentinel ile Yüksek Erişilebilir Redis Kurulumu

Son Güncelleme: Ağustos 2026

Redis Sentinel, Redis önbellek veya oturum depolama katmanını tek sunucu bağımlılığından kurtarmak için kullanılan yüksek erişilebilirlik çözümüdür. Bu rehberde Linux sunucularda Redis Sentinel mimarisini, güvenli kurulum adımlarını, otomatik failover mantığını ve üretim ortamı için dikkat edilmesi gereken optimizasyonları uygulamalı şekilde ele alacağız.

İçindekiler

• Redis Sentinel Nedir?
• Mimari ve Çalışma Mantığı
• Kurulum Öncesi Planlama
• Linux Üzerinde Redis Kurulumu
• Sentinel Yapılandırması
• Güvenlik ve Erişim Kontrolleri
• Failover Testi ve Doğrulama
• Uygulama Entegrasyonu
• İzleme, Yedekleme ve Bakım
• En İyi Uygulamalar
• Sıkça Sorulan Sorular
• Sonuç

Redis Sentinel Nedir?

Redis Sentinel, Redis için izleme, bildirim ve otomatik lider değiştirme yani failover sağlayan yerleşik bir yüksek erişilebilirlik bileşenidir. Standart bir Redis kurulumunda tek bir master düğüm arızalanırsa uygulama önbelleğe, kuyruk verisine veya oturum bilgilerine erişemeyebilir. Sentinel bu riski azaltmak için master düğümü sürekli izler, sorun algılandığında replica düğümlerden birini yeni master olarak seçer ve istemcilere yeni master bilgisini sağlar.

Redis Sentinel özellikle e-ticaret siteleri, WordPress nesne önbelleği, Laravel queue, API rate limit, oturum yönetimi ve gerçek zamanlı sayaçlar gibi kesintiye hassas yapılarda tercih edilir. Buradaki amaç yalnızca performans kazanımı değildir; aynı zamanda Redis katmanının planlı veya plansız kesintilere karşı dayanıklı hale getirilmesidir.

Sentinel bir veri depolama motoru değildir. Veri Redis master ve replica düğümlerinde tutulur. Sentinel ise bu düğümlerin sağlık durumunu kontrol eden, seçim yapan ve yapılandırma değişikliklerini yöneten koordinasyon katmanıdır. Bu nedenle üretim ortamlarında Sentinel süreçlerinin Redis veri süreçlerinden ayrı düşünülmesi, mümkünse farklı sunuculara dağıtılması önerilir.

Mimari ve Çalışma Mantığı

Redis Sentinel mimarisi genellikle en az üç Sentinel süreci ve birden fazla Redis düğümünden oluşur. En basit üretim senaryosunda bir adet master, iki adet replica ve üç adet Sentinel bulunur. Üç Sentinel kullanımı, karar mekanizmasında çoğunluk yani quorum sağlamak için önemlidir. İki Sentinel yerine üç Sentinel kullanmak, ağ bölünmesi gibi durumlarda hatalı failover riskini azaltır.

Temel Bileşenler

• Master Redis: Yazma işlemlerinin yapıldığı ana Redis düğümüdür.
• Replica Redis: Master düğümden veriyi kopyalayan yedek Redis düğümüdür.
• Sentinel Süreci: Redis düğümlerini izler, arıza kararını verir ve gerekiyorsa yeni master seçimini başlatır.
• Quorum: Bir master düğümün arızalı kabul edilmesi için kaç Sentinel tarafından sorunlu görülmesi gerektiğini belirleyen eşik değeridir.
• Failover: Arızalanan master yerine replica düğümlerden birinin master yapılması işlemidir.

Sentinel Karar Süreci

Sentinel önce Redis master düğümünü belirli aralıklarla sorgular. Yanıt alınamazsa düğüm öznel olarak arızalı kabul edilir. Birden fazla Sentinel aynı sonuca ulaşır ve quorum sağlanırsa düğüm nesnel olarak arızalı kabul edilir. Ardından Sentinel süreçlerinden biri lider seçilir ve failover işlemini yönetir. Bu süreçte en uygun replica seçilir, yeni master yapılır ve diğer replica düğümler yeni master üzerinden yeniden eşitlenir.

Kurulum Öncesi Planlama

Redis Sentinel kurulumuna başlamadan önce sunucu sayısı, ağ topolojisi, bellek kapasitesi, güvenlik duvarı kuralları ve yedekleme stratejisi netleştirilmelidir. Redis çoğunlukla bellek içi veri deposu olarak çalıştığı için RAM kapasitesi doğrudan performansı ve stabiliteyi etkiler. Ayrıca ağ gecikmesi yüksek olan düğümler, replikasyon gecikmesine ve yanlış failover kararlarına neden olabilir.

Örnek Topoloji

Bu rehberde üç Linux sunucu üzerinden örnek bir yapı kurgulayacağız. IP adresleri temsilidir; kendi altyapınızda özel ağ IP aralığını kullanmanız daha güvenlidir.

Tek sunucuda birden fazla Sentinel çalıştırmak test ortamı için mümkün olsa da üretim için doğru yaklaşım değildir. Çünkü aynı fiziksel veya sanal sunucunun kapanması durumunda tüm karar mekanizması etkilenebilir. Daha dayanıklı bir altyapı için Corelux Sanal Sunucu veya yüksek kaynak gerektiren yapılarda Kiralık Sunucu seçenekleri değerlendirilebilir.

Kaynak Planlama

• RAM: Redis verisinin tamamını ve ek bellek kullanımını karşılayacak kapasite ayrılmalıdır.
• CPU: Redis tek iş parçacıklı çalışmaya yakın bir model kullandığı için yüksek frekanslı işlemci avantaj sağlar.
• Disk: RDB veya AOF kalıcılığı kullanılacaksa hızlı SSD ya da NVMe disk tercih edilmelidir.
• Ağ: Replica senkronizasyonu için düşük gecikmeli ve paket kaybı düşük özel ağ önerilir.
• Yedekleme: Redis tek başına yedekleme stratejisi değildir; düzenli dış yedekleme planlanmalıdır.

Linux Üzerinde Redis Kurulumu

Kuruluma başlamadan önce tüm sunucularda paket listelerini güncelleyin. Aşağıdaki örnekler Ubuntu tabanlı sistemler içindir. Debian tabanlı sistemlerde de benzer şekilde uygulanabilir. Farklı dağıtımlarda paket yöneticisi değişebilir ancak yapılandırma mantığı aynıdır.

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

Kurulumdan sonra Redis servisinin durumunu kontrol edin.

sudo systemctl status redis-server

Redis varsayılan olarak yalnızca yerel bağlantıları kabul edecek şekilde gelebilir. Sentinel ve replica yapısı için Redis düğümlerinin özel ağ IP adresleri üzerinden birbirine erişebilmesi gerekir. /etc/redis/redis.conf dosyasını düzenleyerek temel ayarları yapılandırın.

sudo nano /etc/redis/redis.conf

Master Redis Ayarları

redis-01 üzerinde aşağıdaki ayarlar örnek olarak kullanılabilir. Parola değerini güçlü ve benzersiz bir değerle değiştirin.

bind 127.0.0.1 10.10.10.11
port 6379
protected-mode yes
requirepass GucluRedisParolasiDegistir
masterauth GucluRedisParolasiDegistir
appendonly yes
appendfsync everysec

Replica Redis Ayarları

redis-02 ve redis-03 üzerinde ilgili IP adresini değiştirerek aşağıdaki ayarlar kullanılabilir.

bind 127.0.0.1 10.10.10.12
port 6379
protected-mode yes
requirepass GucluRedisParolasiDegistir
masterauth GucluRedisParolasiDegistir
replicaof 10.10.10.11 6379
appendonly yes
appendfsync everysec

Yapılandırma sonrası Redis servisini yeniden başlatın.

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

Replica durumunu kontrol etmek için replica sunucuda aşağıdaki komutu çalıştırabilirsiniz.

redis-cli -h 10.10.10.12 -a GucluRedisParolasiDegistir info replication

Çıktıda role:slave veya yeni sürümlerde role:replica benzeri bir ifade görmeniz beklenir. Master tarafında ise bağlı replica sayısı görüntülenmelidir.

Sentinel Yapılandırması

Sentinel yapılandırması için genellikle /etc/redis/sentinel.conf dosyası kullanılır. Bazı dağıtımlarda dosya varsayılan olarak gelmeyebilir; bu durumda elle oluşturabilirsiniz. Aşağıdaki ayarları üç sunucuda da IP adreslerini dikkate alarak uygulayın.

sudo nano /etc/redis/sentinel.conf

Örnek Sentinel yapılandırması:

port 26379
bind 127.0.0.1 10.10.10.11
protected-mode yes
sentinel monitor mymaster 10.10.10.11 6379 2
sentinel auth-pass mymaster GucluRedisParolasiDegistir
sentinel down-after-milliseconds mymaster 5000
sentinel failover-timeout mymaster 60000
sentinel parallel-syncs mymaster 1
logfile /var/log/redis/redis-sentinel.log

sentinel monitor satırındaki mymaster değeri, Sentinel tarafından izlenen master adıdır. Uygulama istemcileri de genellikle bu adı kullanarak aktif master adresini öğrenir. Sondaki 2 değeri quorum değeridir. Üç Sentinel bulunan bir yapıda iki Sentinel aynı master düğümün arızalı olduğunu düşünürse failover süreci başlatılabilir.

Sentinel Servisini Oluşturma

Bazı sistemlerde Sentinel servisi hazır gelir. Hazır gelmiyorsa systemd için basit bir servis dosyası oluşturabilirsiniz.

sudo nano /etc/systemd/system/redis-sentinel.service

[Unit]
Description=Redis Sentinel
After=network.target redis-server.service

[Service]
Type=simple
ExecStart=/usr/bin/redis-sentinel /etc/redis/sentinel.conf --supervised systemd
ExecStop=/bin/kill -s TERM $MAINPID
Restart=always
User=redis
Group=redis

[Install]
WantedBy=multi-user.target

Servisi etkinleştirin ve başlatın.

sudo systemctl daemon-reload
sudo systemctl enable redis-sentinel
sudo systemctl start redis-sentinel
sudo systemctl status redis-sentinel

Sentinel durumunu kontrol etmek için aşağıdaki komut kullanılabilir.

redis-cli -p 26379 sentinel masters

Bu komut, izlenen master düğümünü, quorum değerini, Sentinel sayısını ve mevcut durumu gösterir. Üç sunucuda da Sentinel çalıştığında num-other-sentinels değerinin doğru şekilde artması beklenir.

Güvenlik ve Erişim Kontrolleri

Redis yüksek performanslı bir servis olduğu için doğrudan internete açık bırakılmamalıdır. Sentinel mimarisinde hem Redis portu olan 6379 hem de Sentinel portu olan 26379 yalnızca güvenilir sunuculara açılmalıdır. Özel ağ kullanımı, güvenlik duvarı kısıtlamaları ve güçlü parola zorunludur.

UFW ile Port Kısıtlama

Ubuntu üzerinde ufw kullanıyorsanız yalnızca Redis kümesindeki sunuculara izin verebilirsiniz.

sudo ufw allow from 10.10.10.11 to any port 6379 proto tcp
sudo ufw allow from 10.10.10.12 to any port 6379 proto tcp
sudo ufw allow from 10.10.10.13 to any port 6379 proto tcp
sudo ufw allow from 10.10.10.11 to any port 26379 proto tcp
sudo ufw allow from 10.10.10.12 to any port 26379 proto tcp
sudo ufw allow from 10.10.10.13 to any port 26379 proto tcp
sudo ufw enable
sudo ufw status

Güvenlik Kontrol Listesi

• Genel IP erişimini kapatın: Redis portlarını internete açık bırakmayın.
• Güçlü parola kullanın: requirepass ve masterauth değerlerini tahmin edilemez seçin.
• Özel ağ tercih edin: Redis replikasyon trafiğini mümkünse private network üzerinden taşıyın.
• Yetkisiz komutları sınırlandırın: Yönetim komutlarının uygulama kullanıcıları tarafından çalıştırılmasını engelleyin.
• Logları izleyin: Başarısız bağlantı denemeleri ve failover kayıtları düzenli kontrol edilmelidir.

Daha kritik sistemlerde Redis düğümlerini izole bir ağda konumlandırmak ve uygulama sunucuları ile Redis katmanı arasındaki erişimi minimumda tutmak gerekir. Türkiye lokasyonlu düşük gecikmeli altyapılar için Türkiye VDS Sunucu seçenekleri, Redis tabanlı uygulamalarda erişim süresini düşürmeye yardımcı olabilir.

Failover Testi ve Doğrulama

Kurulum tamamlandıktan sonra failover mekanizmasını test etmeden üretime geçmek doğru değildir. Test sırasında amaç, master düğümün durması halinde Sentinel süreçlerinin yeni master seçimini yapıp yapmadığını görmek ve uygulamanın bu değişime uyum sağlayıp sağlamadığını doğrulamaktır.

Master Düğümü Durdurma

Mevcut master olan redis-01 üzerinde Redis servisini geçici olarak durdurun.

sudo systemctl stop redis-server

Ardından Sentinel loglarını izleyin.

sudo tail -f /var/log/redis/redis-sentinel.log

Birkaç saniye içinde Sentinel master düğümün erişilemez olduğunu algılamalı, quorum sağlanmalı ve replica düğümlerden biri yeni master olarak seçilmelidir. Yeni master bilgisini görmek için herhangi bir Sentinel üzerinde şu komutu çalıştırabilirsiniz.

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

Eski Master Geri Geldiğinde

Eski master yeniden başlatıldığında Sentinel onu otomatik olarak yeni masterın replica düğümü haline getirebilir. Bu davranış, veri tutarlılığı açısından önemlidir. Eski masterın tekrar master rolünü zorla alması önerilmez; rol değişimini Sentinel yönetmelidir.

sudo systemctl start redis-server
redis-cli -h 10.10.10.11 -a GucluRedisParolasiDegistir info replication

Failover testinden sonra uygulamanızın yazma işlemlerini yeni mastera yönlendirdiğini doğrulayın. Eğer uygulama hâlâ eski master IP adresine doğrudan bağlanıyorsa Sentinel mimarisinin faydasından tam olarak yararlanamazsınız.

Uygulama Entegrasyonu

Redis Sentinel mimarisinde uygulamalar sabit bir Redis master IP adresine bağlanmak yerine Sentinel düğümlerini ve master adını kullanmalıdır. Böylece failover sonrasında yeni master adresi otomatik öğrenilebilir. Kullanılan programlama dili veya framework bu noktada önemlidir; istemci kütüphanesinin Sentinel desteği olması gerekir.

Laravel İçin Yaklaşım

Laravel projelerinde Redis bağlantısı genellikle config/database.php ve ortam değişkenleri üzerinden yönetilir. Sentinel destekli istemci kullanıldığında uygulama, mymaster adını ve Sentinel adreslerini bilmelidir. Örnek ortam değişkenleri aşağıdaki gibi düzenlenebilir.

REDIS_CLIENT=phpredis
REDIS_SENTINEL_SERVICE=mymaster
REDIS_SENTINEL_HOSTS=10.10.10.11:26379,10.10.10.12:26379,10.10.10.13:26379
REDIS_PASSWORD=GucluRedisParolasiDegistir

WordPress ve Önbellek Kullanımı

WordPress sitelerinde Redis çoğunlukla nesne önbelleği için kullanılır. Trafiği yüksek WordPress sitelerinde Redis kesintisi sayfa üretim süresini etkileyebilir. Sentinel desteği eklentiye ve kullanılan PHP Redis istemcisine göre değiştiği için üretime geçmeden önce failover testleri mutlaka yapılmalıdır. Paylaşımlı yapı yerine izole kaynak isteniyorsa Corelux Linux Hosting veya daha esnek yapılandırmalar için sanal sunucu seçenekleri değerlendirilebilir.

Doğrudan IP Bağlantısından Kaçınma

Uygulama yapılandırmasında yalnızca 10.10.10.11:6379 gibi tek bir master adresi kullanmak, Sentinel kurulumunu etkisiz hale getirir. Bu durumda master değiştiğinde uygulama bağlantı hatası almaya devam eder. Doğru yaklaşım, uygulamanın Sentinel düğümlerine bağlanması ve aktif masterı Sentinel üzerinden keşfetmesidir.

İzleme, Yedekleme ve Bakım

Redis Sentinel kurmak yüksek erişilebilirlik için güçlü bir adımdır ancak tek başına yeterli değildir. İzleme, kapasite planlama, log kontrolü ve yedekleme süreçleri de aynı ciddiyetle ele alınmalıdır. Redis belleği dolduğunda veri silme politikaları devreye girebilir veya yazma işlemleri başarısız olabilir. Bu nedenle bellek kullanımı, bağlantı sayısı, replikasyon gecikmesi ve failover olayları düzenli izlenmelidir.

İzlenmesi Gereken Metrikler

• used_memory: Redis tarafından kullanılan bellek miktarını gösterir.
• connected_clients: Aktif istemci bağlantı sayısını gösterir.
• master_link_status: Replica düğümlerin master ile bağlantı durumunu gösterir.
• rejected_connections: Bağlantı limitleri nedeniyle reddedilen istemcileri gösterir.
• role: Düğümün master veya replica rolünü gösterir.

Temel kontrol için aşağıdaki komut kullanılabilir.

redis-cli -h 10.10.10.11 -a GucluRedisParolasiDegistir info

Yedekleme Yaklaşımı

Redis Sentinel veriyi yüksek erişilebilir hale getirir ancak insan hatası, yanlış komut, uygulama bugı veya veri bozulması gibi durumlara karşı yedekleme sağlamaz. Bu nedenle RDB dosyaları, AOF dosyaları veya uygulama seviyesindeki kritik veriler düzenli olarak yedeklenmelidir. Kurumsal yapılarda yedekler farklı lokasyonda saklanmalı ve geri dönüş testleri yapılmalıdır. Corelux Yedekleme Hizmeti, sunucu verilerinin planlı şekilde korunması için değerlendirilebilir.

Bakım Sırasında Dikkat Edilecekler

1. Önce replica düğümleri güncelleyin: Master üzerinde işlem yapmadan önce replica düğümlerin sağlıklı olduğundan emin olun.
2. Tek seferde tüm Sentinel süreçlerini kapatmayın: Karar mekanizmasını devre dışı bırakmak failover kabiliyetini ortadan kaldırır.
3. Bakım penceresi planlayın: Kısa kesintiler bile uygulama tarafında hataya neden olabilir.
4. Failover sonrası rolleri kontrol edin: Eski masterın doğru şekilde replica rolüne geçtiğini doğrulayın.

En İyi Uygulamalar

Redis Sentinel kullanırken hedef yalnızca sistemi çalıştırmak değil, beklenmeyen durumlarda öngörülebilir davranan bir yapı kurmaktır. Bunun için yapılandırma dosyalarının standartlaştırılması, erişim politikalarının sıkı tutulması ve test senaryolarının düzenli tekrarlanması gerekir.

• En az üç Sentinel kullanın: Çoğunluk kararının sağlıklı alınması için üç Sentinel önerilir.
• Sentinel ve Redis portlarını sınırlandırın: Portları yalnızca güvenilir IP adreslerine açın.
• Uygulama tarafında Sentinel desteği kullanın: Sabit master IP adresine bağımlı kalmayın.
• Parola ve erişim bilgilerini güvenli saklayın: Uygulama parolalarını kod deposuna açık şekilde yazmayın.
• Failover testini periyodik yapın: Sadece kurulum günü yapılan test yeterli değildir.
• Bellek sınırlarını belirleyin: maxmemory ve uygun silme politikasını kullanım senaryosuna göre ayarlayın.
• Kalıcı veri ihtiyacını doğru analiz edin: Redis önbellek olarak kullanılıyorsa veri kaybı kabul edilebilir olabilir; oturum veya kuyruk için daha dikkatli planlama gerekir.

Redis veriniz kritikse appendonly yes kullanımı değerlendirilebilir. Ancak AOF kalıcılığı disk I/O yükünü artırabilir. Bu nedenle performans ve veri güvenliği arasında dengeli bir karar verilmelidir. Yüksek trafikli projelerde kaynak izolasyonu için Türkiye Kiralık Sunucu seçenekleri, Redis ve uygulama katmanlarını ayrı sunuculara konumlandırmak açısından avantaj sağlayabilir.

Sıkça Sorulan Sorular

Sonuç

Redis Sentinel, Linux sunucularda Redis servisinin yüksek erişilebilir hale getirilmesi için pratik ve güçlü bir çözümdür. Doğru planlanmış üç düğümlü yapı, quorum ayarı, güvenli ağ erişimi, uygulama tarafında Sentinel desteği ve düzenli failover testleri ile Redis kaynaklı kesinti riski önemli ölçüde azaltılabilir.

Üretim ortamında Redis Sentinel kullanırken yedekleme, izleme ve güvenlik adımlarını ihmal etmemek gerekir. Corelux altyapısında Sanal Sunucu, Kiralık Sunucu ve Yedekleme Hizmeti seçenekleriyle Redis tabanlı uygulamalarınız için performanslı, güvenli ve ölçeklenebilir bir yapı kurgulayabilirsiniz.