GET _cluster/health komutu "status": "red" döndürdüğünde iyi bir an olmaz. Cluster'ın bir yerinde bir primary shard'ın atanacak bir düğümü kalmamıştır, o index'e giden aramalar hata vermeye başlar ve saat işlemeye devam eder. Bu rehber, shard'ların neden atanamadığını nasıl bulacağınızı ve cluster'ı tahmin yürütmeden nasıl yeniden yeşile döndüreceğinizi adım adım anlatıyor.
Kısa cevap: Elasticsearch'ün shard'ı neden atanmamış (unassigned) bıraktığını görmek için GET _cluster/allocation/explain çalıştırın, kök nedeni düzeltin (disk alanı, allocation kuralları veya eksik düğüm), ardından POST _cluster/reroute?retry_failed=true çalıştırın. allocate_stale_primary ve allocate_empty_primary komutlarını kesinlikle son çare olarak görün — ikisi de veri kaybettirebilir.
"Red" ve "Unassigned Shards" Aslında Ne Anlama Gelir?
Cluster health tek bir metrik değil, shard durumlarının özetidir. Green, her primary ve replica shard'ın atanmış olduğu anlamına gelir. Yellow, tüm primary'ler atanmış ama en az bir replica'nın atanmamış olduğu durumdur. Red ise en az bir primary shard'ın kendisinin atanamadığı, yani o shard'ın arkasındaki verinin geçici olarak hem okunamaz hem yazılamaz olduğu anlamına gelir.
Yellow ile Red Arasındaki Kritik Fark
Yellow bir cluster can sıkıcıdır ama genellikle acil değildir: veriniz sağlamdır, sadece bir replica bir düğümü beklerken ya da yakalarken yedeklilik geçici olarak azalmıştır. Red cluster ise farklıdır. Etkilenen index aktif trafik alıyorsa, o shard'a değen istekler doğrudan başarısız olur. Yellow'u "izle", red'i ise "dur ve hemen teşhis koy" olarak ele alın.
1. Adım: Allocation Explain API ile Nedeni Bulun
Herhangi bir şeyi değiştirmeden önce, Elasticsearch'e bir shard'ın neden atanamadığını sorun. Cluster allocation explain API tam olarak bunun için var:
GET _cluster/allocation/explainGövde olmadan çağrıldığında Elasticsearch rastgele bir atanmamış shard'ı açıklar; ilk bakış için idare eder ama birden fazla shard farklı nedenlerle atanmamışsa güvenilir değildir. Hangi index ve shard numarasıyla ilgilendiğinizi öğrendikten sonra (GET _cat/shards?h=index,shard,prirep,state,unassigned.reason&s=state ile), bunu açıkça belirtin:
GET _cluster/allocation/explain
{
"index": "my-index",
"shard": 0,
"primary": true
}"decisions" Dizisini Okumak
Yanıt, Elasticsearch'in değerlendirdiği her düğümü listeleyen bir node_allocation_decisions dizisi içerir; her düğüm için de hangi allocation decider'ın "hayır" dediğini ve nedenini gösteren bir deciders dökümü bulunur — disk alanı, filtreleme kuralları, allocation awareness, shard limitleri ve benzerleri. Bir shard takıldığında en değerli çıktı budur; bunu okumadan doğrudan bir reroute komutuna geçmek genellikle yanlış şeyi düzeltmek anlamına gelir.
En Sık Karşılaşacağınız Nedenler
1. Disk Watermark Aşıldı
Varsayılan olarak Elasticsearch, bir düğüm %85 disk kullanımı düşük watermark'ını aştığında o düğüme yeni shard atamayı durdurur; daha yüksek watermark'ta ise mevcut shard'ları başka yere taşıyabilir bile. deciders içinde disk_threshold geçiyorsa çözüm bir reroute komutu değil, disk alanıdır — alan açın, kapasite ekleyin ya da ILM'i daha agresif silme/rollover yapacak şekilde ayarlayın.
2. Shard Allocation Filtering veya Awareness Kuralları
Index seviyesindeki index.routing.allocation.* ayarları ya da cluster genelindeki allocation awareness (rack/zone awareness) kuralları, hiçbir düğüm o kuralı karşılamıyorsa bir shard'ı meşru şekilde atanmamış bırakabilir — genellikle bir düğüm devre dışı bırakıldığında veya etiketi değiştirildiğinde ayar güncellenmediği için yaşanır.
3. Replica Sayısı İçin Yeterli Uygun Düğüm Yok
number_of_replicas, bir kopyayı yasal olarak barındırabilecek düğüm sayısından fazlaysa (örneğin number_of_replicas: 1 ayarlı tek düğümlü bir geliştirme cluster'ında), o replica sonsuza kadar atanmamış kalır. Cluster'ın geri kalanı sağlıklı göründüğü için bu durum kolayca gözden kaçar.
4. Bir Düğüm Recovery Sırasında Ayrıldı
Shard'lar taşınırken veya recovery yaparken bir data node cluster'dan ayrılırsa, o shard'lar düğüm geri dönene veya Elasticsearch onları başka yere yeniden atayana kadar atanmamış kalır. En kötüsünü varsaymadan önce GET _cat/nodes ve cluster loglarını yakın zamandaki ayrılmalar için kontrol edin.
5. Bozuk veya Kurtarılamaz Bir Primary
En az görülen ama en ciddi durum: primary'nin verisi, Elasticsearch'in bulabildiği her kopyada kayıp veya bozuk. Allocation explain çıktısı genellikle NO_VALID_SHARD_COPY veya benzerini gösterir. Veri kaybının gerçek bir olasılık haline geldiği senaryo tam olarak budur; aşağıda ele alınıyor.
Çözüm: Güvenliden Son Çareye
Önce Başarısız Allocation'ı Yeniden Deneyin
Elasticsearch, sonsuz bir yeniden deneme döngüsünden kaçınmak için beş ardışık allocation başarısızlığından sonra bir shard'ı yeniden denemeyi bırakır. Altta yatan neden zaten çözülmüşse (disk açıldı, düğüm tekrar katıldı), basit bir yeniden deneme genellikle cluster ayarlarına dokunmadan sorunu giderir:
POST _cluster/reroute?retry_failed=trueManuel Reroute (Dikkatle)
Bir shard hâlâ hareket etmiyorsa, açık bir allocate_replica veya move komutuyla POST _cluster/reroute çağırmak, tek bir shard için otomatik allocator'ı geçersiz kılmanızı sağlar. Ne olacağını taahhüt etmeden önce görmek için her zaman önce ?dry_run=true ile çalıştırın.
Yalnızca Son Çare: Stale veya Boş Primary Atamak
Allocation explain çıktısı geçerli bir shard kopyası olmadığını doğruladığında, Elasticsearch allocate_stale_primary (daha eski bir kopyayı kabul etmek, son yazmaları kaybetmek) veya allocate_empty_primary (o shard için tam veri kaybını kabul edip index'in kilidini açmak) seçeneklerini sunar. Bu komutlar bir nedenden dolayı var, ama açıkça yıkıcıdırlar — yalnızca gerçekten daha iyi bir kopya olmadığını doğruladıktan sonra ve yalnızca ihtiyaç duyulan spesifik shard üzerinde kullanın.
Bir Sonraki Red Cluster'ı Önlemek
Çoğu red-cluster olayı, önlenebilir küçük bir dizi eksikliğe dayanır: küçük hacimlerde varsayılanda bırakılmış disk watermark'ları, altyapı değişikliğinden sonra hiç güncellenmemiş allocation awareness kuralları ve unassigned_shards > 0 için bir alarma dönüşmeden önce hiçbir uyarı kurulmamış olması. Ölçek büyüdükçe cluster durumunu gözle takip etmek tam olarak zorlaştığı yerdir — Elasticsearch monitoring eklentimiz atanmamış shard'ları ve allocation nedenlerini doğrudan gösterir, yukarıdaki güvenli yeniden deneme akışı için rehberli bir fix-allocation adımı içerir; böylece bu API çağrılarını gece yarısı ezberlemeniz gerekmez.
Bunun gerçek ölçekte nasıl yaşandığını görmek için — yüzlerce terabayt ve yoğun indexing altında tekrarlayan RED olayları — petabyte ölçekli bir cluster'ı tekrarlayan RED olaylarından sonra stabilize etmeye dair DataDome vaka analizimize göz atın.
Sık Sorulan Sorular
Yellow Cluster Veri Kaybettiğim Anlamına mı Gelir?
Hayır. Yellow, her primary shard'ın atanmış olduğu, verinizin tamamen okunabilir ve yazılabilir olduğu anlamına gelir — yalnızca replica yedekliliği azalmıştır. Sakin şekilde düzeltin: düğümleri yeniden başlatmak yerine replica'nın neden yerleştirilemediğini (genellikle düğüm sayısı veya disk) kontrol edin.
Elasticsearch Başarısız Allocation'ı Neden Yeniden Denemeyi Bıraktı?
Aynı shard için beş ardışık allocation başarısızlığından sonra Elasticsearch, sıcak bir yeniden deneme döngüsünden kaçınmak için otomatik denemeyi durdurur. Altta yatan nedeni düzelttikten sonra POST _cluster/reroute?retry_failed=true komutu yeniden denemesini söyler.
Cluster'ı Yeşile Döndürmek İçin Atanmamış Shard'ı Silebilir miyim?
Tek bir shard'ı silemezsiniz. Gerçekçi seçenekleriniz şunlar: etkilenen index'i snapshot'tan geri yükleyin, veri yeniden üretilebilirse index'i tamamen silip yeniden oluşturun ya da — gerçek bir son çare olarak — allocate_empty_primary ile o shard için veri kaybını kabul edin.
Cluster Red Olmadan Önce Nasıl Uyarı Alırım?
Yalnızca cluster durumuna değil, unassigned_shards > 0 ve %85 düşük watermark'a yaklaşan disk kullanımına alarm kurun. Her iki sinyal de red olayından çok önce ortaya çıkar; bu da sorun henüz yellow seviyesindeyken harekete geçme zamanı tanır.