Veritabanı Yönetimi

    Redis Cluster Kurulumu

    Altı düğümlü Redis Cluster kurmanın, slot yönetiminin ve düğüm eklemenin adım adım rehberi.

    10 dk okuma Güncellendi: 25 Ağustos 2026

    Tek bir Redis sunucusu belleğe sığdığı sürece muhteşem çalışır. Sorun veri kümeniz makinenin RAM'ini aşmaya başladığında ortaya çıkar: dikey büyüme bir yere kadar gider, sonra ya çok pahalı ya da fiziksel olarak imkânsız hale gelir. Redis Cluster tam bu noktada devreye girer; veriyi birden fazla düğüme otomatik olarak dağıtır, her parçaya bir yedek atar ve bir düğüm çöktüğünde yedeğini otomatik yükselterek hizmete devam eder.

    Bu rehberde Redis Cluster'ın hash slot mimarisini, üç master ve üç replika içeren gerçek bir kurulumu sıfırdan yapmayı, redis-cli --cluster komutlarıyla kümeyi oluşturup doğrulamayı, çalışan bir kümeye yeni düğüm ekleyip slot taşımayı, MOVED ve ASK yönlendirmelerinin ne anlama geldiğini ve çok anahtarlı işlemlerde hash tag kullanmayı anlatacağım. Sonda da cluster'a geçenlerin en sık yaşadığı sürprizleri topladım.

    Hash Slot Mimarisi ve Cluster Ne Zaman Gerekir#

    Redis Cluster, anahtar alanını 16384 hash slot'a böler. Her anahtarın hangi slota düşeceği CRC16(anahtar) mod 16384 formülüyle belirlenir ve her master düğüm bu slotların bir aralığından sorumludur. Üç master'lı bir kümede tipik dağılım şöyledir: 0-5460, 5461-10922, 10923-16383.

    Bu mimarinin en önemli sonucu şudur: istemci hangi anahtarın hangi düğümde olduğunu bilir. Cluster'ı destekleyen bir istemci kütüphanesi, açılışta slot haritasını çeker ve isteği doğrudan doğru düğüme gönderir; ortada proxy yoktur, dolayısıyla ek gecikme de yoktur. Yanlış düğüme giden bir istek MOVED yanıtı alır ve istemci haritasını günceller.

    Cluster'a geçmeden önce gerçekten ihtiyacınız olduğundan emin olun, çünkü getirdiği kısıtlar ciddidir:

    KonuTek düğümCluster
    Bellek sınırıTek makinenin RAM'iDüğüm sayısı × RAM
    Çok anahtarlı komut (MGET, SUNION)SerbestYalnızca aynı slottaki anahtarlar
    Birden fazla veritabanı (SELECT 1)VarYok, sadece DB 0
    Lua betikleriSerbestAnahtarlar aynı slotta olmalı
    Otomatik devretmeYok (Sentinel gerekir)Dahili
    İstemci desteğiHer kütüphaneCluster modunu desteklemeli

    Kaba bir karar kuralı: veri kümeniz tek makinenin belleğine rahatça sığıyorsa cluster'a geçmeyin. Yüksek erişilebilirlik istiyorsanız ama bellek sorununuz yoksa Redis Sentinel çok daha basit bir çözümdür. Cluster, asıl olarak yatay ölçekleme ihtiyacının cevabıdır.

    Altı Düğümlü Kümeyi Kurmak#

    Redis Cluster en az üç master ile çalışır; bu, oy çoğunluğuyla devretme kararı verebilmek için gerekli minimumdur. Üretim için standart yapı üç master artı üç replikadır. Aşağıdaki örnekte altı düğümü aynı makinede farklı portlarda kuruyorum; üretimde her düğümü ayrı sunucuya koyacaksınız, yapılandırma mantığı birebir aynıdır.

    Her düğüm için ayrı bir yapılandırma dosyası oluşturun:

    # /etc/redis/cluster-7001.conf
    port 7001
    bind 0.0.0.0 -::1
    protected-mode no
    
    cluster-enabled yes
    cluster-config-file nodes-7001.conf
    cluster-node-timeout 5000
    
    # Her düğümün kendi veri dizini olmalı
    dir /var/lib/redis/7001
    appendonly yes
    appendfsync everysec
    
    # Küme içi iletişim için parola (her düğümde AYNI olmalı)
    requirepass guclu-cluster-parolasi
    masterauth guclu-cluster-parolasi
    
    pidfile /var/run/redis/redis-7001.pid
    logfile /var/log/redis/redis-7001.log
    daemonize no
    

    Dizinleri hazırlayıp altı düğümü de başlatın. cluster-config-file dosyasını elle düzenlemeyin; Redis onu kendisi yönetir ve düğümün kimliğini orada tutar.

    for P in 7001 7002 7003 7004 7005 7006; do
      sudo install -d -o redis -g redis /var/lib/redis/$P
      sudo sed "s/7001/$P/g" /etc/redis/cluster-7001.conf | sudo tee /etc/redis/cluster-$P.conf >/dev/null
      sudo systemctl start redis-cluster@$P
    done
    

    Düğümler ayakta ama birbirlerini tanımıyor. Kümeyi oluşturan komut şudur; --cluster-replicas 1 her master'a bir replika atanmasını söyler:

    redis-cli -a guclu-cluster-parolasi --cluster create \
      127.0.0.1:7001 127.0.0.1:7002 127.0.0.1:7003 \
      127.0.0.1:7004 127.0.0.1:7005 127.0.0.1:7006 \
      --cluster-replicas 1
    

    Komut önerdiği slot dağılımını gösterir ve onay ister. yes yazdıktan sonra düğümler el sıkışır, slotlar atanır ve replikalar master'larına bağlanır. Kurulumu doğrulayın:

    redis-cli -a guclu-cluster-parolasi -p 7001 cluster info | head -5
    # cluster_state:ok
    # cluster_slots_assigned:16384
    # cluster_known_nodes:6
    # cluster_size:3
    
    redis-cli -a guclu-cluster-parolasi -p 7001 cluster nodes
    

    cluster_state:ok ve cluster_slots_assigned:16384 görmeniz şart. Slot sayısı 16384'ten azsa kümede boşluk var demektir ve o slotlara düşen anahtarlar erişilemez olur.

    Küme Portları ve Ağ Gereksinimleri#

    Redis Cluster'ın en çok sorun çıkaran tarafı ağdır ve sebebi basit: her düğüm iki port kullanır. Birincisi istemcilerin bağlandığı normal port, ikincisi ise küme içi dedikodu (gossip) protokolü için kullanılan ve varsayılan olarak normal portun 10000 fazlası olan porttur.

    PortKim kullanırÖrnek
    İstemci portuUygulama sunucuları7001
    Küme veri yolu portuYalnızca diğer düğümler17001

    Yani 7001-7006 arasında çalışan bir kümede güvenlik duvarınız 17001-17006 portlarını da düğümler arasında açmalıdır. Bu ikinci grubu unutmak, kümenin kurulmuş görünüp bir süre sonra düğümleri "fail" olarak işaretlemesine yol açar ve teşhisi zordur çünkü istemci tarafında her şey normal görünür.

    # Sadece küme düğümleri arasında; internete AÇMAYIN
    sudo ufw allow from 185.12.34.57 to any port 7001:7006 proto tcp
    sudo ufw allow from 185.12.34.57 to any port 17001:17006 proto tcp
    

    İkinci kritik nokta cluster-announce-ip ayarıdır. Düğümler birbirlerine kendi IP'lerini bildirir; NAT arkasında, Docker içinde ya da özel ağda çalışıyorsanız bildirilen IP diğer düğümlerin erişemeyeceği bir adres olabilir. Bu durumda ayarı açıkça verin:

    cluster-announce-ip 185.12.34.56
    cluster-announce-port 7001
    cluster-announce-bus-port 17001
    

    Kümeyi asla halka açık bir arayüzde şifresiz bırakmayın. protected-mode no ayarını yalnızca güvenlik duvarınız düğümler dışındaki her şeyi engellediğinden eminken kullanın; aksi halde DDoS koruma katmanı bile açık bir Redis portunu kurtarmaz.

    Anahtar Dağılımı, MOVED ve Hash Tag#

    Cluster moduna geçtiğinizde redis-cli ile bağlanma biçiminiz değişir. -c bayrağı olmadan bağlanırsanız, sorumlusu başka düğüm olan bir anahtarı istediğinizde hata alırsınız:

    # -c OLMADAN: yönlendirme yapılmaz
    redis-cli -p 7001 -a guclu-cluster-parolasi SET musteri:42 "Ahmet"
    # (error) MOVED 8000 127.0.0.1:7002
    
    # -c İLE: istemci yönlendirmeyi takip eder
    redis-cli -c -p 7001 -a guclu-cluster-parolasi SET musteri:42 "Ahmet"
    # -> Redirected to slot [8000] located at 127.0.0.1:7002
    # OK
    

    Bir anahtarın hangi slota düştüğünü öğrenmek isterseniz:

    redis-cli -p 7001 CLUSTER KEYSLOT musteri:42
    # (integer) 8000
    
    # Slot dağılımının özetini gör
    redis-cli -a guclu-cluster-parolasi --cluster check 127.0.0.1:7001
    

    Cluster'ın en büyük kısıtı, birden fazla anahtara dokunan komutların yalnızca aynı slottaki anahtarlarla çalışmasıdır. MGET musteri:42 siparis:99 komutu, iki anahtar farklı slotlara düşüyorsa CROSSSLOT hatası verir. Çözüm hash tag'dir: anahtar adının süslü parantez içindeki kısmı varsa, slot hesabı yalnızca o kısma bakılarak yapılır.

    # Farklı slotlar — CROSSSLOT hatası
    # MGET musteri:42:profil musteri:42:ayarlar
    
    # Hash tag ile aynı slota zorlanmış anahtarlar
    redis-cli -c -p 7001 -a guclu-cluster-parolasi MSET "{musteri:42}:profil" "..." "{musteri:42}:ayarlar" "..."
    redis-cli -c -p 7001 -a guclu-cluster-parolasi MGET "{musteri:42}:profil" "{musteri:42}:ayarlar"
    

    Hash tag'i dikkatli kullanın. Aynı tag'i taşıyan tüm anahtarlar aynı düğüme gider; çok popüler bir tag seçerseniz o düğüm diğerlerinden kat kat fazla yük alır ve dağıtımın anlamı kalmaz. Uygulama tasarımında hangi anahtarların birlikte sorgulandığını önceden belirleyip tag'i o granülerlikte seçmek gerekir.

    Düğüm Ekleme ve Slot Taşıma#

    Kümeyi büyütmek iki adımlı bir iştir: önce yeni düğümü kümeye tanıtırsınız, sonra ona slot taşırsınız. Yalnızca tanıtmak yetmez; slot almayan bir master boş durur ve hiçbir işe yaramaz.

    # 1) Yeni master'ı kümeye ekle (ikinci adres, kümeden bilinen herhangi bir düğüm)
    redis-cli -a guclu-cluster-parolasi --cluster add-node \
      127.0.0.1:7007 127.0.0.1:7001
    
    # 2) Ona replika ekle
    redis-cli -a guclu-cluster-parolasi --cluster add-node \
      127.0.0.1:7008 127.0.0.1:7001 \
      --cluster-slave --cluster-master-id <7007-node-id>
    

    Slot taşıma işlemi reshard komutuyla yapılır ve etkileşimli olarak kaç slot, nereden nereye taşınacağını sorar. Betikleştirmek için parametreleri komut satırında verebilirsiniz:

    # 4096 slotu mevcut master'lardan yeni düğüme taşı
    redis-cli -a guclu-cluster-parolasi --cluster reshard 127.0.0.1:7001 \
      --cluster-from all \
      --cluster-to <7007-node-id> \
      --cluster-slots 4096 \
      --cluster-yes
    

    Taşıma canlı yapılır; anahtarlar parça parça aktarılırken küme hizmet vermeye devam eder. Taşınmakta olan bir slottaki anahtar istendiğinde istemci ASK yönlendirmesi alır — bu, MOVED'dan farklıdır ve "bu anahtar geçici olarak şurada, ama slot haritanı güncelleme" anlamına gelir. Cluster destekli istemciler bunu şeffaf biçimde halleder.

    Dengeyi kontrol etmek ve gerekirse otomatik düzeltmek için:

    # Slot dağılımını dengele
    redis-cli -a guclu-cluster-parolasi --cluster rebalance 127.0.0.1:7001
    
    # Düğüm çıkarmadan önce slotlarını boşaltın, sonra silin
    redis-cli -a guclu-cluster-parolasi --cluster del-node 127.0.0.1:7001 <node-id>
    

    Bir düğümü kümeden çıkarırken sırayı ters yapmak sık bir hatadır: önce slotları başka düğüme taşımadan del-node çalıştırırsanız komut reddedilir, zorlarsanız o slotlardaki veri kaybolur.

    Sık Yapılan Hatalar ve Tuzaklar#

    Küme veri yolu portlarını açmayı unutmak. Her düğüm normal portunun 10000 fazlasını kullanır. 16379 gibi portlar güvenlik duvarında kapalıysa düğümler dedikodu yapamaz, birbirlerini arızalı sanar ve küme sürekli devretme yapmaya çalışır. Sorunun teşhisi zordur çünkü tek düğüme yapılan testler çalışır görünür.

    İki master ile küme kurmaya çalışmak. Devretme kararı çoğunluk oyuyla verilir; iki master'lı bir kümede biri çöktüğünde kalan tek düğüm çoğunluğu sağlayamaz ve küme durur. Minimum üç master şarttır ve bu üçü mümkünse farklı fiziksel makinelerde olmalıdır.

    Aynı fiziksel makinede master ve replikasını tutmak. Cluster otomatik olarak replikayı master'dan farklı bir düğüme atar ama aynı makinedeki iki Redis örneğini ayırt edemez. Makine çökerse hem master hem replika gider. Üretimde her düğüm ayrı sunucuda olmalıdır.

    Cluster desteklemeyen istemci kullanmak. Uygulamanızın Redis kütüphanesi cluster modunu bilmiyorsa her istekte MOVED hatası alırsınız. Kullandığınız kütüphanenin cluster istemcisine geçmeniz ve bağlantı yapılandırmasında tüm başlangıç düğümlerini vermeniz gerekir.

    SELECT ve çok veritabanlı kullanım. Cluster modunda yalnızca 0 numaralı veritabanı vardır. Uygulamanız veriyi ayırmak için SELECT 1, SELECT 2 kullanıyorsa cluster'a geçmeden önce anahtar öneki tabanlı bir ayrıma geçmeniz gerekir.

    Bellek planlamasını atlamak. Her düğüm kendi verisine ek olarak, kalıcılık açıksa fork() sırasında geçici bellek sıçraması yaşar. Küme genelinde maxmemory toplamını fiziksel belleğin tamamına eşitlemek, ilk snapshot denemesinde düğüm kaybetmek demektir. Bellek ayarlarının ayrıntısı için Redis bellek optimizasyonu yazısına bakabilirsiniz.

    Sıkça Sorulan Sorular#

    Redis Cluster için en az kaç sunucu gerekir#

    Teknik minimum üç master'dır, çünkü devretme kararı çoğunluk oyuyla verilir ve iki düğümle çoğunluk oluşmaz. Üretim için tavsiye edilen yapı üç master artı üç replika, yani altı Redis örneğidir. Bunları üç fiziksel sunucuya dağıtabilirsiniz (her sunucuda bir master ve başka bir master'ın replikası), ama ideal olan altı ayrı sunucudur. Aynı makineye master ve kendi replikasını koymak, tek arızada ikisini birden kaybetmek demektir.

    Cluster ile Sentinel arasındaki fark nedir#

    Sentinel yalnızca yüksek erişilebilirlik sağlar: veri tek bir master'da durur, Sentinel süreçleri onu izler ve çöktüğünde replikalardan birini yükseltir. Cluster ise buna ek olarak veriyi düğümler arasında böler, yani bellek kapasitesini de ölçekler. Bellek sorununuz yoksa ve sadece devretme istiyorsanız Sentinel çok daha basit ve uygulama tarafında daha az kısıt getirir.

    MGET ve MSET neden CROSSSLOT hatası veriyor#

    Çünkü cluster modunda birden fazla anahtara dokunan komutlar, tüm anahtarların aynı hash slotta olmasını gerektirir. musteri:42 ve siparis:99 farklı slotlara düşer ve tek bir düğümde atomik olarak işlenemezler. Çözüm hash tag kullanmaktır: anahtarları {musteri:42}:profil gibi adlandırırsanız slot hesabı yalnızca süslü parantez içindeki kısma bakar ve tüm bu anahtarlar aynı düğüme düşer.

    Bir düğüm çökerse ne olur#

    Diğer düğümler cluster-node-timeout süresi boyunca ona ulaşamazsa arızalı olarak işaretler. Master'ların çoğunluğu bu kararı onaylarsa, çöken master'ın replikalarından biri otomatik olarak master'a yükseltilir ve slotlarını devralır. Bu süreç genellikle birkaç saniye sürer. Çöken master'ın replikası yoksa o slotlar erişilemez hale gelir ve cluster-require-full-coverage ayarı yes ise (varsayılan) tüm küme yazma kabul etmeyi durdurur.

    Cluster'a geçtikten sonra uygulamamda ne değişir#

    Üç şey değişir. Birincisi, Redis kütüphanenizi cluster istemcisine geçirmeniz ve bağlantı yapılandırmasında birden fazla başlangıç düğümü vermeniz gerekir. İkincisi, çok anahtarlı komutlar ve Lua betikleri için hash tag disiplini uygulamanız gerekir. Üçüncüsü, SELECT ile veritabanı ayırma imkânı kalmaz; anahtar öneki kullanmalısınız. Bu üç değişikliği önceden planlamadan geçiş yaparsanız uygulamanız kısmen çalışır durumda kalır.

    Veri dağılımının dengeli olduğunu nasıl kontrol ederim#

    redis-cli --cluster check <düğüm> komutu her master'ın kaç slot ve kaç anahtar tuttuğunu listeler. Slot sayıları eşit ama anahtar sayıları çok farklıysa, muhtemelen hash tag'leri fazla geniş seçmişsinizdir ve belirli tag'ler tek düğümde birikmiştir. redis-cli --cluster rebalance komutu slotları eşitler ama anahtar dağılımındaki dengesizliği çözmez; onun çözümü anahtar adlandırma şemanızı gözden geçirmektir.

    Kapanış#

    Redis Cluster'ı kurarken aklınızda tutmanız gereken birkaç şey var: en az üç master ile başlayın ve her düğümü ayrı makineye koyun, küme veri yolu portlarını (normal port + 10000) güvenlik duvarında düğümler arasında açmayı unutmayın, uygulamanızı cluster destekli bir istemciye geçirin ve çok anahtarlı işlemler için hash tag disiplinini baştan kurun. Bir de şunu unutmayın: cluster yatay ölçekleme için vardır; yalnızca yüksek erişilebilirlik istiyorsanız Sentinel çok daha basit bir yoldur.

    Altı düğümlü bir küme kurmak için birbirine düşük gecikmeyle bağlı birden fazla sunucuya ihtiyacınız olur. Aynı altyapıda hızlıca çoğaltabileceğiniz bulut sunucu veya VDS paketlerimiz bu topolojiyi kurmak için uygun bir taban sağlar; yüksek bellek gerektiren düğümler için dedicated sunucu daha öngörülebilir bir kaynak sunar. Küme kurulumu, izleme ve devretme testlerini devretmek isterseniz sunucu yönetimi hizmetimiz bu işi üstlenir.

    RedisClusterÖlçekleme

    Uygulamaya geçmeye hazır mısınız?

    NVMe SSD, ücretsiz SSL ve %99.9 uptime garantisiyle Clou.TR hosting ve sunucu çözümleriyle projenizi hayata geçirin.