Elastik Arama: Atanmamış Parçalar, nasıl düzeltilir?

4 düğümlü bir ES kümesi var:

number_of_replicas: 1
search01 - master: false, data: false
search02 - master: true, data: true
search03 - master: false, data: true
search04 - master: false, data: true

Search03'ü yeniden başlatmak zorunda kaldım ve geri döndüğünde, kümeye sorun yaşamadı, ancak atanmamış 7 parça bıraktı.

{
  "cluster_name" : "tweedle",
  "status" : "yellow",
  "timed_out" : false,
  "number_of_nodes" : 4,
  "number_of_data_nodes" : 3,
  "active_primary_shards" : 15,
  "active_shards" : 23,
  "relocating_shards" : 0,
  "initializing_shards" : 0,
  "unassigned_shards" : 7
}

Şimdi kümem sarı durumda. Bu sorunu çözmenin en iyi yolu nedir?

• Kırıkları silmek (iptal etmek)?
• Kırıkları başka bir düğüme taşı?
• Kırıkları düğüme atayın mı?
• 'Number_of_replicas' güncellensin mi?
• Tamamen başka bir şey mi?

İlginç bir şekilde, yeni bir dizin eklendiğinde, bu düğüm üzerinde çalışmaya başladı ve kümenin geri kalanıyla iyi oynadı, atanmamış kırıkları bıraktı.

Soruyu takip et: Bunun gerçekleşmesine neden olmak için yanlış bir şey mi yapıyorum? Bir düğüm yeniden başlatıldığında bu şekilde davranan bir kümeye fazla güvenmiyorum.

NOT: Herhangi bir nedenle tek bir düğüm kümesi çalıştırıyorsanız, aşağıdakileri yapmanız gerekebilir:

curl -XPUT 'localhost:9200/_settings' -d '
{
    "index" : {
        "number_of_replicas" : 0
    }
}'

Varsayılan olarak, Elasticsearch dinamik olarak düğümlere parçaları atayacaktır. Ancak, parça ayırmayı devre dışı bıraktıysanız (belki de yeniden başlatmayı yeniden başlattınız ve yeniden etkinleştirmeyi unuttuysanız), parça ayırmayı yeniden etkinleştirebilirsiniz.

# v0.90.x and earlier
curl -XPUT 'localhost:9200/_settings' -d '{
    "index.routing.allocation.disable_allocation": false
}'

# v1.0+
curl -XPUT 'localhost:9200/_cluster/settings' -d '{
    "transient" : {
        "cluster.routing.allocation.enable" : "all"
    }
}'

Elasticsearch daha sonra parçaları normal şekilde yeniden atayacaktır. Bu yavaş olabilir, yükseltmeyi indices.recovery.max_bytes_per_secve cluster.routing.allocation.node_concurrent_recoverieshızlandırmayı düşünebilirsiniz .

Hâlâ sorun görüyorsanız, muhtemelen başka bir şey yanlıştır, bu nedenle hatalar için Elasticsearch günlüklerinize bakın. Eğer EsRejectedExecutionExceptioniplik havuzları görürseniz çok küçük olabilir .

Son olarak, yeniden yönlendirme API'sı ile bir parçayı bir düğüme açık olarak yeniden atayabilirsiniz .

# Suppose shard 4 of index "my-index" is unassigned, so you want to
# assign it to node search03:
curl -XPOST 'localhost:9200/_cluster/reroute' -d '{
    "commands": [{
        "allocate": {
            "index": "my-index",
            "shard": 4,
            "node": "search03",
            "allow_primary": 1
        }
    }]
}'

Tamam, bunu ES desteğinden yardım alarak çözdüm. Tüm düğümlerde (veya sorunun nedeni olduğunu düşündüğünüz düğümlerde) API'ya aşağıdaki komutu verin:

curl -XPUT 'localhost:9200/<index>/_settings' \
    -d '{"index.routing.allocation.disable_allocation": false}'

<index>suçlu olduğuna inandığınız dizin nerede . Hiçbir fikriniz yoksa, bunu tüm düğümlerde çalıştırın:

curl -XPUT 'localhost:9200/_settings' \
    -d '{"index.routing.allocation.disable_allocation": false}'

Bu satırı yaml config'ime de ekledim ve o zamandan beri sunucu / hizmetin yeniden başlatılması sorunsuz oldu. Kırıklar hemen yeniden tahsis edildi.

FWIW, sorulan bir soruyu yanıtlamak için, makinenizde 60G'den az RAM yoksa MAX_HEAP_SIZE değerini 30G olarak ayarlayın, bu durumda kullanılabilir belleğin yarısına ayarlayın.

Referanslar

• Kırık Ayırma Bilinci

Bu küçük bash betiği yeniden atamaya zorlayacak, veri kaybedebilirsiniz.

NODE="YOUR NODE NAME"
IFS=$'\n'
for line in $(curl -s 'localhost:9200/_cat/shards' | fgrep UNASSIGNED); do
  INDEX=$(echo $line | (awk '{print $1}'))
  SHARD=$(echo $line | (awk '{print $2}'))

  curl -XPOST 'localhost:9200/_cluster/reroute' -d '{
     "commands": [
        {
            "allocate": {
                "index": "'$INDEX'",
                "shard": '$SHARD',
                "node": "'$NODE'",
                "allow_primary": true
          }
        }
    ]
  }'
done

Benim için çalışan tek şey number_of_replicas (2 kopya vardı, bu yüzden 1 olarak değiştirdim ve sonra 2 olarak değiştirildi) değişiyordu.

İlk:

PUT /myindex/_settings
{
    "index" : {
        "number_of_replicas" : 1
     }
}

Sonra:

PUT /myindex/_settings
{
    "index" : {
        "number_of_replicas" : 2
     }
}

(Ben zaten bu soruda şaşırdım )

Aşağıdaki yapılandırma herkese ayarlanmışsa, Elasticsearch otomatik olarak kırıkları ayırır. Bu yapılandırma, bir rest api ve cluster.routing.allocation.enable: all kullanılarak ayarlanabilir

Aşağıdaki yapılandırma uygulandıktan sonra bile es, parçaları otomatik olarak atayamazsa, parçaları kendiniz atamaya zorlamanız gerekir. Bunun için ES resmi bağlantısı

Atanmamış tüm parçaları kümeye atamaya zorlamak için bir senaryo yazdım.

Aşağıdaki dizi, atanmamış parçaları dengelemek istediğiniz düğümlerin listesini içerir

#!/bin/bash
array=( node1 node2 node3 )
node_counter=0
length=${#array[@]}
IFS=$'\n'
for line in $(curl -s 'http://127.0.0.1:9200/_cat/shards'|  fgrep UNASSIGNED); do
    INDEX=$(echo $line | (awk '{print $1}'))
    SHARD=$(echo $line | (awk '{print $2}'))
    NODE=${array[$node_counter]}
    echo $NODE
    curl -XPOST 'http://127.0.0.1:9200/_cluster/reroute' -d '{
        "commands": [
        {
            "allocate": {
                "index": "'$INDEX'",
                "shard": '$SHARD',
                "node": "'$NODE'",
                "allow_primary": true
            }
        }
        ]
    }'
    node_counter=$(((node_counter)%length +1))
done

Bugün aynı kırıkları tahsisi sorunuyla sıkıştım. W. Andrew Loe III'ün cevabında önerdiği senaryo benim için işe yaramadı, bu yüzden biraz değiştirdim ve sonunda çalıştı:

#!/usr/bin/env bash

# The script performs force relocation of all unassigned shards, 
# of all indices to a specified node (NODE variable)

ES_HOST="<elasticsearch host>"
NODE="<node name>"

curl ${ES_HOST}:9200/_cat/shards > shards
grep "UNASSIGNED" shards > unassigned_shards

while read LINE; do
  IFS=" " read -r -a ARRAY <<< "$LINE"
  INDEX=${ARRAY[0]}
  SHARD=${ARRAY[1]}

  echo "Relocating:"
  echo "Index: ${INDEX}"
  echo "Shard: ${SHARD}"
  echo "To node: ${NODE}"

  curl -s -XPOST "${ES_HOST}:9200/_cluster/reroute" -d "{
    \"commands\": [
       {
         \"allocate\": {
           \"index\": \"${INDEX}\",
           \"shard\": ${SHARD},
           \"node\": \"${NODE}\",
           \"allow_primary\": true
         }
       }
     ]
  }"; echo
  echo "------------------------------"
done <unassigned_shards

rm shards
rm unassigned_shards

exit 0

Şimdi, ben bir tür Bash gurusu değilim, ama senaryo benim durumum için gerçekten işe yaradı. "ES_HOST" ve "NODE" değişkenleri için uygun değerleri belirtmeniz gerektiğini unutmayın.

Benim durumumda, sabit disk alanı üst sınırına ulaşıldı.

Bu makaleye bakın: https://www.elastic.co/guide/en/elasticsearch/reference/current/disk-allocator.html

Temel olarak, koştum:

PUT /_cluster/settings
{
  "transient": {
    "cluster.routing.allocation.disk.watermark.low": "90%",
    "cluster.routing.allocation.disk.watermark.high": "95%",
    "cluster.info.update.interval": "1m"
  }
}

Böylece, <% 90 sabit disk alanı kullanılıyorsa ayırır ve>% 95 sabit disk alanı kullanılıyorsa bir parçayı kümedeki başka bir makineye taşır; ve her 1 dakikada bir kontrol eder.

Belki birisine yardımcı olur, ancak aynı sorunu yaşadım ve bir kütüğün çok büyük hale gelmesinin neden olduğu depolama alanı eksikliğinden kaynaklanıyordu.

Umarım birine yardım eder! :)

Benim durumumda, yeni bir dizin oluşturduğumda varsayılan sayı_of_replicas 1 olarak ayarlanır. Ve kümemdeki düğüm sayısı yalnızca biriydi, bu yüzden çoğaltmayı oluşturmak için fazladan düğüm yoktu, bu nedenle sağlık sarıya dönüyordu. Bu yüzden settings özelliği ile dizin oluşturduktan ve number_of_replicas 0 olarak ayarladığımda. Sonra iyi çalıştı. Bu yardımcı olur umarım.

PUT /customer
{
    "settings": {
        "number_of_replicas": 0
    }
}

Ben aynı sorun vardı ama kök nedeni sürüm numaraları (iki düğüm 1.4.2 (sorunları ile) ve 1.4.4 iki düğüm (Tamam) bir fark oldu. Birinci ve ikinci yanıtlar ("index.routing.allocation.disable_allocation" değerini false olarak ve "cluster.routing.allocation.enable" değerini "all" olarak ayarlamak) çalışmadı.

Bununla birlikte, @Wilfred Hughes ("cluster.routing.allocation.enable" öğesini "geçici" kullanarak "all" olarak ayarlama) yanıtı bana aşağıdaki ifade ile bir hata verdi:

[NO (hedef düğüm sürümü [1.4.2], kaynak düğüm sürümünden [1.4.4] daha eski)]]

Eski düğümleri 1.4.4'e güncelledikten sonra, bu düğümler diğer iyi düğümlerle yeniden birleşmeye başladı.

Ben de bu sorunu yaşıyordum ve çözmek için kolay bir yol buldum.

• Atanmamış parçaların dizinini al

  $ curl -XGET http://172.16.4.140:9200/_cat/shards
  

• Küratör Araçları'nı yükleyin ve dizini silmek için kullanın

  $ curator --host 172.16.4.140 delete indices --older-than 1 \
         --timestring '%Y.%m.%d' --time-unit days --prefix logstash
  

  NOT: Benim durumumda, dizin 2016-04-21 günün logstash

• Sonra kırıkları tekrar kontrol edin, atanmamış tüm kırıklar gider!

Ben de bu durumla karşılaştım ve sonunda düzelttim.

İlk olarak, durumumu açıklayacağım. Elastik Arama kümesinde iki düğüm var, birbirlerini bulabilirler, ancak "number_of_replicas" ayarlarıyla bir dizin oluşturduğumda : 2 , "number_of_shards": 5, ES sarı sinyali gösterir ve atanmamış_shards 5'tir.

Sorun, 1 ile değerini ayarladığınızda , hepsi iyi olduğundan number_of_replicas değeri nedeniyle oluşur .

Benim durumumda, eski paylaşımları olan eski bir düğüm kümeye katılıyordu, bu yüzden eski düğümü kapatıp atanmamış parçalar içeren dizinleri silmemiz gerekiyordu.

Yukarıdaki önerilerin birkaçını denedim ve ne yazık ki hiçbiri işe yaramadı. Alt ortamımızda uygulamaların hatalarını yazdığı bir "Günlük" dizinimiz var. Tek düğümlü bir kümedir. Benim için çözen şey, düğüm için YML yapılandırma dosyasını kontrol etmek ve varsayılan ayarın hala "gateway.expected_nodes: 2" olduğunu görmekti. Bu, sahip olduğumuz diğer ayarları geçersiz kılıyordu. Ne zaman bu düğümde bir indeks oluştursak, 5 parçadan 3'ünü fantom 2. düğüme yaymaya çalışırdı. Bu nedenle, bunlar atanmamış olarak görünür ve hiçbir zaman 1. ve tek düğüme taşınamazlar.

Çözüm, yapılandırmayı düzenleyerek "gateway.expected_nodes" ayarını 1 olarak değiştirdi, böylece kümede bulunmayan kardeşini aramayı bıraktı ve Elastik hizmet örneğini yeniden başlattı. Ayrıca, dizini silmek ve yeni bir dizin oluşturmak zorunda kaldı. Dizini oluşturduktan sonra, parçaların hepsi 1. ve tek düğümde ortaya çıktı ve hiçbiri atanmadı.

# Set how many nodes are expected in this cluster. Once these N nodes
# are up (and recover_after_nodes is met), begin recovery process immediately
# (without waiting for recover_after_time to expire):
#
# gateway.expected_nodes: 2
gateway.expected_nodes: 1

Benim için bu, geliştirici konsolundan çalıştırılarak çözüldü: "POST / _cluster / reroute? Retry_failed"

.....

Hangi indekslerin kırmızı olduğunu görmek için indeks listesine bakıp işe başladım.

"get /_cat/shards?h=[INDEXNAME Cialis,shard,prirep,state,unassigned.reason"

ve parçaların ALLOCATION_FAILED durumunda sıkışmış olduğunu gördü, bu nedenle yukarıdaki yeniden denemenin çalıştırılması ayırmayı yeniden denemelerine neden oldu.

Yardımcı olabilir, ancak ES'yi gömülü modda çalıştırmaya çalışırken bu sorunu yaşadım. Düzeltme düğümü yerel (doğru) ayarlanmış olduğundan emin olmaktı.

Atanmamış parçalar için bir başka olası neden de, kümenizin Elasticsearch ikili dosyasının birden fazla sürümünü çalıştırmasıdır.

en son sürümden önceki sürümlere parça çoğaltması çalışmaz

Bu, atanmamış parçalar için temel bir neden olabilir.

Elastik Belgeler - Yuvarlama Yükseltme Süreci

Ben de aynı sorunla karşılaştım. Bu, elastics aramayı yeniden başlatmadan önce parça tahsisini geçici olarak false değerine ayarlayarak önlenebilir, ancak zaten yoksa, atanmamış parçalar düzeltilmez.

Benim durumumda veri düğümünde boş disk alanı olmamasından kaynaklandı. Yeniden başlatmadan sonra veri düğümünde hala atanmamış parçalar, ancak master tarafından tanınmadıkları yerlerde.

Sadece düğümlerden 1 tanesini temizlemek benim için çoğaltma işlemini başlattı. Tüm veriler 1 veri düğümünden diğerine kopyalanması gerektiğinden bu oldukça yavaş bir işlemdir.

Atanmamış parçaları silmeyi veya bunları belirli bir veri düğümüne manuel olarak atamayı denedim. Atanmamış parçalar görünmeye devam ettiği ve sağlık durumu tekrar tekrar "kırmızı" olduğu için işe yaramadı. Sonra veri düğümlerinden birinin "yeniden başlatma" durumunda kalmış olduğunu fark ettim. Veri düğümlerinin sayısını azalttım, öldürdüm. Sorun artık tekrarlanamıyor.

Kendini iyileştiren gibi görünmeyen parçalara sahip iki endeksim vardı. Sonunda bunu geçici olarak fazladan bir veri düğümü ekleyerek çözdüm ^[1] . Endeksler sağlıklı hale geldikten ve her şey yeşile döndükten sonra, ekstra düğümü çıkardım ve sistem yeniden dengeleyebildi (tekrar) ve sağlıklı bir duruma yerleşebildi.

Aynı anda birden fazla veri düğümünü öldürmekten kaçınmak iyi bir fikirdir (bu duruma nasıl geldim). Muhtemelen, kırıklardan en az biri için herhangi bir kopya / kopya saklayamadım. Neyse ki, Kubernetes disk depolama alanını tuttu ve veri düğümünü yeniden başlattığımda yeniden kullandım.

... biraz zaman geçti ...

Peki, bu kez sadece bir düğüm eklemek işe yaramadı (bir şey olması için birkaç dakika bekledikten sonra), bu yüzden REST API'de dolaşmaya başladım.

GET /_cluster/allocation/explain

Bu benim yeni düğümümü gösterdi "decision": "YES".

Bu arada, önceden mevcut olan tüm düğümlerin "decision": "NO"nedeni vardı "the node is above the low watermark cluster setting". Bu muhtemelen daha önce değindiğim durumdan farklı bir durumdu.

Sonra Aşağıdaki basit POST yapılan ^[2] hiçbir vücutla , vitese şeyler başladı ...

POST /_cluster/reroute

Diğer notlar:

• Çok yardımcı oldular : https://datadoghq.com/blog/elasticsearch-unassigned-shards

• Çalışabilecek başka bir şey. Set cluster_concurrent_rebalanceiçin 0daha sonra, null- Göstereceğim olarak burada .

^{[1] Yeterli tavan boşluğunuz varsa Kubernetes'te yapmak oldukça kolaydır: sadece durum tablosunu gösterge paneli aracılığıyla ölçeklendirin.}

^{[2] Kibana "Dev Tools" arayüzünü kullanarak SSH / exec mermileriyle uğraşmak zorunda kalmadım.}

İlk önce

"İndex.number_of_replicas"

1 ile (düğümler senkronize oluncaya kadar bekleyin) daha sonra 1 azaldı, bu da atanmamış kırıkları etkili bir şekilde temizler ve küme herhangi bir veri kaybetme riski olmadan tekrar Yeşil olur.

Daha iyi yollar olduğuna inanıyorum ama bu benim için daha kolay.

Bu yardımcı olur umarım.

Bozuk kırıklarla uğraşırken, çoğaltma faktörünü 0 olarak ayarlayabilir ve ardından orijinal değerine geri ayarlayabilirsiniz. Bu, tüm bozuk kırıklarınız olmasa bile çoğunu temizlemeli ve kümedeki yeni kopyaların yerini değiştirmelidir.

0 çoğaltma faktörü kullanmak için atanmamış çoğaltmaları olan dizinleri ayarlama:

curl -XGET http://localhost:9200/_cat/shards |\
  grep UNASSIGNED | grep ' r ' |\
  awk '{print $1}' |\
  xargs -I {} curl -XPUT http://localhost:9200/{}/_settings -H "Content-Type: application/json" \
  -d '{ "index":{ "number_of_replicas": 0}}'

Bunları 1 olarak ayarlama:

curl -XGET http://localhost:9200/_cat/shards |\
  awk '{print $1}' |\
  xargs -I {} curl -XPUT http://localhost:9200/{}/_settings -H "Content-Type: application/json" \
  -d '{ "index":{ "number_of_replicas": 1}}'

Not: Farklı dizinler için farklı çoğaltma faktörleriniz varsa bunu çalıştırmayın. Bu, tüm dizinler için çoğaltma faktörünü 1 olarak kodlar.