Örnek sorular
Redis Replication SentinelZorluk 1
Bir Redis instance'ında REPLICAOF <master-ip> <master-port> çalıştırmak ne yapar?
- aKeyspace'i iki instance arasında shard'lar
- bInstance'ı belirtilen master'ın replica'sı yapar✓
- cİki instance'ı tek bir cluster node'unda birleştirir
- dInstance'ı verilen master için bir Sentinel yapar
Açıklama:Instance'ı verilen master'ın replica'sı yapar; instance önce ilk senkronizasyonu yapar, sonra master'ın write akışını sürekli uygular. Bunun shard'lamayla ilgisi yoktur (a), iki node'u cluster'da birleştirmez (c) ve instance'ı Sentinel'e çevirmez — Sentinel ayrı bir süreçtir (d).
Redis Replication SentinelZorluk 1
Redis master-replica replikasyonu varsayılan olarak senkron mudur, asenkron mudur?
- aSenkron — master her zaman dönmeden önce her replica'nın acknowledge etmesini bekler
- bAnahtarın TTL'sine bağlıdır
- cAsenkron — master replica uygulamasını beklemek zorunda değildir✓
- dSenkron, ama sadece bir MULTI/EXEC bloğu içindeki anahtarlar için
Açıklama:Redis replikasyonu varsayılan olarak asenkrondur: master, write'ı yerel olarak uyguladığı anda client'a yanıt verir ve sonrasında beklemeden replica'lara yayar. WAIT ile daha güçlü acknowledgement'a geçilebilir ama bu varsayılan değildir (a, d). Replikasyon modunun anahtarın TTL'siyle ilgisi yoktur (b).
Redis Replication SentinelZorluk 1
Varsayılan ayarlarla bir client bir Redis replica'sına doğrudan write yapabilir mi?
- aHayır — replica'lar varsayılan olarak write'ları reddeder✓
- bEvet, ve write sessizce master'a yönlendirilir
- cEvet, ama sadece TTL'i olmayan anahtarlar için
- dEvet, replica'lar write kabul eder ve sonradan master ile çakışmaları uzlaştırır
Açıklama:Replica'lar varsayılan olarak replica-read-only yes ile çalışır, bu yüzden replica'ya doğrudan write denemesi uygulanmak veya yönlendirilmek yerine client'a READONLY hatası döner (b, d yanlış — otomatik yönlendirme ya da çakışma uzlaştırma yoktur). Bunun TTL ile ilgisi yoktur (c).
Redis Replication SentinelZorluk 1
Redis Sentinel'in birincil amacı nedir?
- aAnahtarları birden fazla Redis node'u arasında shard'lamak
- bRDB snapshot'larını daha hızlı transfer için sıkıştırmak
- cReplica'lar için bir Lua scripting sandbox'ı sağlamak
- dNode'ları izlemek ve failover'ı koordine etmek✓
Açıklama:Sentinel, master ve replica'ların sağlığını izler, durum değişikliklerini bildirir ve mevcut master'ın down olduğu tespit edildiğinde bir replica'yı otomatik olarak master'a terfi ettirebilir. Shard'lama Redis Cluster'ın işidir, Sentinel'in değil (a); Sentinel RDB dosyalarını sıkıştırmaz (b) ya da scripting sandbox'ı sağlamaz (c).
Redis Replication SentinelZorluk 1
Bir uygulama, başka bir client'ın master'a yazdığı bir anahtarı hemen ardından bir replica'dan okuyor. Replica eski değeri döndürüyor. En olası açıklama nedir?
- aReplica yanlış yapılandırılmıştır ve bug olarak ele alınmalıdır
- bReplica, normal asenkron replikasyon gecikmesi nedeniyle write'ı henüz uygulamamıştır✓
- cRedis replica'ları var olan anahtarlar için asla güncelleme almaz, sadece yeni anahtarlar için alır
- dMaster, quorum hatası nedeniyle write'ı reddetmiştir
Açıklama:Replikasyon asenkron olduğundan, master'ın zaten acknowledge ettiği bir write'ı replica'nın henüz uygulamadığı küçük bir pencere vardır; replica'dan okumak master'a göre hafif geride kalmış bir değer döndürebilir. Bu beklenen bir davranıştır, yanlış yapılandırma değildir (a); replica'lar var olan anahtarlara yapılan güncellemeleri de alır (c); burada master'ın write'ı reddettiğine dair hiçbir işaret yoktur (d).
Redis Replication SentinelZorluk 1
Redis replikasyonu master ile replica'ları arasında nasıl bir ilişki kurar?
- aÇift yönlü — her iki tarafta yapılan write'lar diğerine yayılır
- bSabit bir yön yok — hangi node'un verisi daha güncelse o kaynak olur
- cTek yönlü — write'lar master'dan replica'lara akar, tersi olmaz✓
- dReplication backlog her döndüğünde yön değişir
Açıklama:Redis replikasyonu tek yönlüdür: master, tek write kaynağıdır ve replica'lar ondan gelen write akışını uygular. Çift yönlü değildir (a) ve yön, güncellik durumuna ya da backlog rotasyonuna göre dinamik değil, role göre sabittir (b, d).