ElasticSearch: Mảnh vỡ chưa được gán, làm thế nào để khắc phục?

Tôi có một cụm ES với 4 nút:

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

Tôi đã phải khởi động lại search03, và khi nó quay trở lại, nó đã nối lại cụm đó không có vấn đề gì, nhưng để lại 7 mảnh vỡ chưa được gán nằm.

{
  "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
}

Bây giờ cụm của tôi đang ở trạng thái màu vàng. Cách tốt nhất để giải quyết vấn đề này là gì?

• Xóa (hủy) các mảnh vỡ?
• Di chuyển các mảnh sang nút khác?
• Phân bổ các mảnh vỡ cho nút?
• Cập nhật 'number_of numplicas' thành 2?
• Cái gì khác hoàn toàn?

Thật thú vị, khi một chỉ mục mới được thêm vào, nút đó bắt đầu hoạt động trên nó và chơi tốt với phần còn lại của cụm, nó chỉ để lại các phân đoạn chưa được gán.

Theo dõi câu hỏi: tôi đang làm gì sai để khiến điều này xảy ra ngay từ đầu? Tôi không có nhiều niềm tin vào một cụm hoạt động theo cách này khi một nút được khởi động lại.

LƯU Ý: Nếu bạn đang chạy một cụm nút đơn vì một số lý do, bạn có thể chỉ cần thực hiện các thao tác sau:

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

Theo mặc định, Elaticsearch sẽ gán lại các phân đoạn cho các nút một cách linh hoạt. Tuy nhiên, nếu bạn đã vô hiệu hóa phân bổ phân đoạn (có lẽ bạn đã khởi động lại và quên bật lại), bạn có thể bật lại phân bổ phân đoạn.

# 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"
    }
}'

Elaticsearch sau đó sẽ chỉ định lại các mảnh vỡ như bình thường. Điều này có thể chậm, xem xét nâng cao indices.recovery.max_bytes_per_secvà cluster.routing.allocation.node_concurrent_recoveriestăng tốc nó.

Nếu bạn vẫn thấy có vấn đề, có thể có điều gì đó không ổn, vì vậy hãy xem nhật ký tìm kiếm của bạn. Nếu bạn thấy nhóm EsRejectedExecutionExceptionchủ đề của bạn có thể quá nhỏ .

Cuối cùng, bạn có thể gán lại một cách rõ ràng một phân đoạn cho một nút bằng API định tuyến lại .

# 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
        }
    }]
}'

OK, tôi đã giải quyết vấn đề này với một số trợ giúp từ bộ phận hỗ trợ ES. Ban hành lệnh sau cho API trên tất cả các nút (hoặc các nút mà bạn cho là nguyên nhân của sự cố):

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

đâu <index>là chỉ số mà bạn tin là thủ phạm. Nếu bạn không có ý tưởng, chỉ cần chạy nó trên tất cả các nút:

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

Tôi cũng đã thêm dòng này vào cấu hình yaml của mình và kể từ đó, mọi khởi động lại của máy chủ / dịch vụ đều không có vấn đề gì. Các mảnh vỡ phân bổ lại ngay lập tức.

FWIW, để trả lời câu hỏi tìm kiếm, hãy đặt MAX_HEAP_SIZE thành 30G trừ khi máy của bạn có RAM dưới 60G, trong trường hợp đó đặt nó thành một nửa bộ nhớ khả dụng.

Người giới thiệu

• Nhận thức phân bổ Shard

Kịch bản bash nhỏ này sẽ vũ trang gán lại, bạn có thể mất dữ liệu.

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

Điều duy nhất hiệu quả với tôi là thay đổi number_of numplicas (tôi có 2 bản sao, vì vậy tôi đã đổi nó thành 1 và sau đó đổi lại thành 2).

Đầu tiên:

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

Sau đó:

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

(Tôi đã hỏi nó trong câu hỏi này )

Elaticsearch tự động phân bổ các phân đoạn nếu cấu hình bên dưới được đặt thành tất cả. Cấu hình này có thể được đặt bằng api còn lại cũng cluster.routing.allocation.enable: all

Nếu ngay cả sau khi ứng dụng cấu hình bên dưới, es không tự động gán các phân đoạn, thì bạn phải tự gán các phân đoạn đó. ES liên kết chính thức cho điều này

Tôi đã viết một kịch bản để buộc gán tất cả các phân đoạn chưa được gán trên cụm.

mảng bên dưới chứa danh sách các nút trong đó bạn muốn cân bằng các phân đoạn chưa được gán

#!/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

Tôi đã bị mắc kẹt ngày hôm nay với cùng một vấn đề phân bổ mảnh vỡ. Kịch bản mà W. Andrew Loe III đã đề xuất trong câu trả lời của anh ấy không phù hợp với tôi, vì vậy tôi đã sửa đổi nó một chút và cuối cùng nó cũng có hiệu quả:

#!/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

Bây giờ, tôi không phải là một bậc thầy Bash, nhưng kịch bản thực sự hiệu quả với trường hợp của tôi. Lưu ý rằng bạn sẽ cần chỉ định các giá trị phù hợp cho các biến "ES_HOST" và "NODE".

Trong trường hợp của tôi, không gian đĩa cứng giới hạn trên đã đạt được.

Nhìn vào bài viết này: https://www.elastic.co/guide/en/elaticsearch/reference/civerse/disk-allocator.html

Về cơ bản, tôi đã chạy:

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

Vì vậy, nó sẽ phân bổ nếu <90% dung lượng ổ cứng được sử dụng và di chuyển phân đoạn sang một máy khác trong cụm nếu> 95% dung lượng ổ cứng được sử dụng; và nó kiểm tra cứ sau 1 phút.

Có thể nó giúp được ai đó, nhưng tôi gặp vấn đề tương tự và đó là do thiếu không gian lưu trữ gây ra bởi một bản ghi quá lớn.

Hy vọng nó sẽ giúp được ai đó! :)

Trong trường hợp của tôi, khi tôi tạo một chỉ mục mới thì số_of numplicas mặc định được đặt là 1. Và số nút trong cụm của tôi chỉ là một nên không có nút phụ để tạo bản sao, vì vậy sức khỏe chuyển sang màu vàng. Vì vậy, khi tôi tạo chỉ mục với thuộc tính cài đặt và đặt number_of numplicas là 0. Sau đó, nó hoạt động tốt. Hi vọng điêu nay co ich.

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

Tôi có cùng một vấn đề nhưng nguyên nhân gốc là sự khác biệt về số phiên bản (1.4.2 trên hai nút (có vấn đề) và 1.4.4 trên hai nút (ok)). Câu trả lời thứ nhất và thứ hai (đặt "index.routing.allocation.disable_allocation" thành false và đặt "cluster.routing.allocation.enable" thành "all") không hoạt động.

Tuy nhiên, câu trả lời của @Wilfred Hughes (đặt "cluster.routing.allocation.enable" thành "tất cả" bằng cách sử dụng tạm thời) đã cho tôi một lỗi với câu lệnh sau:

[NO (phiên bản nút đích [1.4.2] cũ hơn phiên bản nút nguồn [1.4.4])]

Sau khi cập nhật các nút cũ lên 1.4.4, các nút này bắt đầu nối lại với các nút tốt khác.

Tôi cũng gặp vấn đề này và tôi đã tìm ra một cách dễ dàng để giải quyết nó.

• Lấy chỉ số của các phân đoạn chưa được gán

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

• Cài đặt công cụ giám tuyển và sử dụng nó để xóa chỉ mục

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

  LƯU Ý: Trong trường hợp của tôi, chỉ mục là logstash của ngày 2016-04-21

• Sau đó kiểm tra các mảnh vỡ một lần nữa, tất cả các mảnh vỡ chưa được phân bổ đi

Tôi cũng gặp tình huống này và cuối cùng đã sửa nó.

Đầu tiên, tôi sẽ mô tả tình huống của tôi. Tôi có hai nút trong cụm ElasticSearch, chúng có thể tìm thấy nhau, nhưng khi tôi tạo một chỉ mục với cài đặt "number_of numplicas": 2 , "number_of_shards": 5, ES hiển thị tín hiệu màu vàng và unassign_shards là 5.

Sự cố xảy ra do giá trị của number_of numplicas , khi tôi đặt giá trị của nó bằng 1 , tất cả đều ổn.

Trong trường hợp của tôi, một nút cũ với các cổ phiếu cũ đã tham gia vào cụm, vì vậy chúng tôi phải tắt nút cũ và xóa các chỉ mục với các phân đoạn chưa được gán.

Tôi đã thử một vài gợi ý ở trên và thật không may, không ai trong số họ làm việc. Chúng tôi có một chỉ mục "Nhật ký" trong môi trường thấp hơn nơi các ứng dụng viết lỗi của họ. Nó là một cụm nút đơn. Điều đã giải quyết nó cho tôi là kiểm tra tệp cấu hình YML cho nút và thấy rằng nó vẫn có cài đặt mặc định "gateway.azed_nodes: 2". Điều này đã ghi đè bất kỳ cài đặt nào khác mà chúng tôi có. Bất cứ khi nào chúng tôi sẽ tạo một chỉ mục trên nút này, nó sẽ cố gắng trải 3 trên 5 phân đoạn cho nút thứ 2 ảo. Do đó, chúng sẽ xuất hiện dưới dạng không được gán và chúng không bao giờ có thể được chuyển đến nút đầu tiên và duy nhất.

Giải pháp là chỉnh sửa cấu hình, thay đổi cài đặt "gateway.azed_nodes" thành 1, do đó, nó sẽ thoát khỏi việc tìm kiếm người anh em không bao giờ được tìm thấy trong cụm và khởi động lại phiên bản dịch vụ Đàn hồi. Ngoài ra, tôi đã phải xóa chỉ mục và tạo một chỉ mục mới. Sau khi tạo chỉ mục, tất cả các phân đoạn đều hiển thị trên nút đầu tiên và duy nhất và không có gì được chỉ định.

# 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

Đối với tôi, điều này đã được giải quyết bằng cách chạy nó từ bảng điều khiển dev: "POST / _cluster / reroute? Retry_fails"

.....

Tôi bắt đầu bằng cách nhìn vào danh sách chỉ mục để xem chỉ số nào màu đỏ và sau đó chạy

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

và thấy rằng nó có các mảnh vỡ bị kẹt trong trạng thái ALLOCATION_FAILED, do đó, việc chạy thử lại ở trên khiến chúng phải thử lại phân bổ.

Có thể giúp, nhưng tôi gặp vấn đề này khi cố chạy ES ở chế độ nhúng. Khắc phục là để đảm bảo rằng Node đã được đặt cục bộ (đúng).

Một lý do có thể khác cho các phân đoạn chưa được gán là cụm của bạn đang chạy nhiều hơn một phiên bản nhị phân Elaticsearch.

Bản sao shard từ phiên bản mới hơn sang phiên bản trước sẽ không hoạt động

Đây có thể là một nguyên nhân gốc rễ cho các mảnh vỡ chưa được gán.

Tài liệu đàn hồi - Quy trình nâng cấp cán

Tôi chạy vào chính xác cùng một vấn đề. Điều này có thể được ngăn chặn bằng cách tạm thời đặt phân bổ phân đoạn thành sai trước khi khởi động lại elaticsearch, nhưng điều này không khắc phục được các phân đoạn chưa được gán nếu chúng đã ở đó.

Trong trường hợp của tôi, đó là do thiếu không gian đĩa trống trên nút dữ liệu. Các phân đoạn không được gán nơi vẫn còn trên nút dữ liệu sau khi khởi động lại nhưng chúng không được chủ nhân nhận ra.

Chỉ cần làm sạch 1 trong số các nút từ đĩa đã bắt đầu quá trình sao chép cho tôi. Đây là một quá trình khá chậm vì tất cả dữ liệu phải được sao chép từ 1 nút dữ liệu sang nút khác.

Tôi đã cố gắng xóa các phân đoạn chưa được gán hoặc gán chúng theo cách thủ công cho nút dữ liệu cụ thể. Nó không hoạt động vì các mảnh vỡ không được chỉ định liên tục xuất hiện và tình trạng sức khỏe bị "đỏ" nhiều lần. Sau đó, tôi nhận thấy rằng một trong các nút dữ liệu bị kẹt trong trạng thái "khởi động lại". Tôi giảm số lượng nút dữ liệu, giết nó. Vấn đề là không thể tái sản xuất nữa.

Tôi có hai chỉ số với các mảnh vỡ không được chỉ định mà dường như không tự phục hồi. Cuối cùng tôi đã giải quyết điều này bằng cách tạm thời thêm một nút dữ liệu bổ sung ^[1] . Sau khi các chỉ số trở nên khỏe mạnh và mọi thứ ổn định thành màu xanh lá cây, tôi đã loại bỏ nút bổ sung và hệ thống có thể cân bằng lại (một lần nữa) và ổn định trạng thái khỏe mạnh.

Đó là một ý tưởng tốt để tránh tiêu diệt nhiều nút dữ liệu cùng một lúc (đó là cách tôi đã vào trạng thái này). Có khả năng, tôi đã thất bại trong việc bảo quản bất kỳ bản sao / bản sao nào cho ít nhất một trong các phân đoạn. May mắn thay, Kubernetes giữ bộ lưu trữ đĩa xung quanh và sử dụng lại khi tôi khởi chạy lại nút dữ liệu.

... Một thời gian đã trôi qua ...

Chà, lần này chỉ thêm một nút dường như không hoạt động (sau khi chờ vài phút để điều gì đó xảy ra), vì vậy tôi bắt đầu chọc ngoáy trong API REST.

GET /_cluster/allocation/explain

Điều này cho thấy nút mới của tôi với "decision": "YES".

Nhân tiện, tất cả các nút có sẵn là "decision": "NO"do "the node is above the low watermark cluster setting". Vì vậy, đây có lẽ là một trường hợp khác với trường hợp tôi đã giải quyết trước đây.

Sau đó, tôi đã thực hiện POST đơn giản sau đây ^[2] mà không có cơ thể , thứ đã đá mọi thứ vào thiết bị ...

POST /_cluster/reroute

Ghi chú khác:

• Rất hữu ích: https://datadoghq.com/blog/elaticsearch-unassign-shards

• Một cái gì đó khác có thể làm việc. Đặt cluster_concurrent_rebalancethành 0, sau đó đến null- như tôi chứng minh ở đây .

^{[1] Khá dễ thực hiện trong Kubernetes nếu bạn có đủ khoảng trống: chỉ cần thu nhỏ bộ trạng thái thông qua bảng điều khiển.}

^{[2] Sử dụng giao diện "Công cụ phát triển" của Kibana, tôi không phải bận tâm với trình bao SSH / exec.}

Tôi chỉ mới tăng

"index.number_of numplicas"

bằng 1 (đợi cho đến khi các nút được đồng bộ hóa) sau đó giảm đi 1 sau đó, điều này sẽ loại bỏ hiệu quả các phân đoạn không được gán và cụm lại có màu xanh mà không có nguy cơ mất dữ liệu.

Tôi tin rằng có những cách tốt hơn nhưng điều này dễ dàng hơn cho tôi.

Hi vọng điêu nay co ich.

Khi xử lý các phân đoạn bị hỏng, bạn có thể đặt hệ số sao chép thành 0 và sau đó đặt lại về giá trị ban đầu. Điều này sẽ làm rõ hầu hết nếu không phải tất cả các phân đoạn bị hỏng của bạn và di chuyển các bản sao mới trong cụm.

Đặt chỉ mục với các bản sao chưa được gán để sử dụng hệ số sao chép là 0:

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}}'

Đặt chúng trở lại 1:

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}}'

Lưu ý: Không chạy cái này nếu bạn có các yếu tố sao chép khác nhau cho các chỉ mục khác nhau. Điều này sẽ mã hóa hệ số sao chép cho tất cả các chỉ mục thành 1.