ELASTICSEARCH健康red的解決

今天慣例看統計報表, 才發現es集群悲劇了......昨天下午到今天早上, 持續報錯, 寫了1G的錯誤日志>_<#(暫無監控....)

當前狀態: 單台機器, 單節點(空集群), 200W 數據, 500+shrads, 約3G大小

以下是幾個問題的處理過程

大量unassigned shards

其實剛搭完運行時就是status: yellow(所有主分片可用，但存在不可用的從分片), 只有一個節點, 主分片啟動並運行正常, 可以成功處理請求, 但是存在unassigned_shards, 即存在沒有被分配到節點的從分片.(只有一個節點.....)

.當時數據量小, 就暫時沒關注. 然后, 隨着時間推移, 出現了大量unassigned shards

curl -XGET http://localhost:9200/_cluster/health\?pretty
{
  "cluster_name" : "elasticsearch",
  "status" : "yellow",
  "timed_out" : false,
  "number_of_nodes" : 2,
  "number_of_data_nodes" : 1,
  "active_primary_shards" : 538,
  "active_shards" : 538,
  "relocating_shards" : 0,
  "initializing_shards" : 0,
  "unassigned_shards" : 558,
"number_of_pending_tasks" : 0
}

處理方式: 找了台內網機器, 部署另一個節點(保證cluster.name一致即可, 自動發現, 贊一個). 當然, 如果你資源有限只有一台機器, 使用相同命令再啟動一個es實例也行. 再次檢查集群健康, 發現unassigned_shards減少, active_shards增多.

操作完后, 集群健康從yellow恢復到 green

status: red

集群健康惡化了......

這次檢查發現是status: red(存在不可用的主要分片)

curl -XGET http://localhost:9200/_cluster/health\?pretty
{
  "cluster_name" : "elasticsearch",
  "status" : "red",    // missing some primary shards
  "timed_out" : false,
  "number_of_nodes" : 4,
  "number_of_data_nodes" : 2,
  "active_primary_shards" : 538,
  "active_shards" : 1076,
  "relocating_shards" : 0,
  "initializing_shards" : 0,
  "unassigned_shards" : 20,  // where your lost primary shards are.
  "number_of_pending_tasks" : 0
}

fix unassigned shards

開始着手修復

查看所有分片狀態

curl -XGET http://localhost:9200/_cat/shards

找出UNASSIGNED分片

curl -s "http://localhost:9200/_cat/shards" | grep UNASSIGNED
pv-2015.05.22                 3 p UNASSIGNED
pv-2015.05.22                 3 r UNASSIGNED
pv-2015.05.22                 1 p UNASSIGNED
pv-2015.05.22                 1 r UNASSIGNED

查詢得到master節點的唯一標識

curl 'localhost:9200/_nodes/process?pretty'

{
  "cluster_name" : "elasticsearch",
  "nodes" : {
    "AfUyuXmGTESHXpwi4OExxx" : {
      "name" : "Master",
     ....
      "attributes" : {
        "master" : "true"
      },
.....

執行reroute(分多次, 變更shard的值為UNASSIGNED查詢結果中編號, 上一步查詢結果是1和3)

curl -XPOST 'localhost:9200/_cluster/reroute' -d '{
        "commands" : [ {
              "allocate" : {
                  "index" : "pv-2015.05.22",
                  "shard" : 1,
                  "node" : "AfUyuXmGTESHXpwi4OExxx",
                  "allow_primary" : true
              }
            }
        ]
    }'

批量處理的腳本(當數量很多的話, 注意替換node的名字)

#!/bin/bash

for index in $(curl -s 'http://localhost:9200/_cat/shards' | grep UNASSIGNED | awk '{print $1}' | sort | uniq); do for shard in $(curl -s 'http://localhost:9200/_cat/shards' | grep UNASSIGNED | grep $index | awk '{print $2}' | sort | uniq); do echo $index $shard curl -XPOST 'localhost:9200/_cluster/reroute' -d "{  'commands' : [ {  'allocate' : {  'index' : $index,  'shard' : $shard,  'node' : 'Master',  'allow_primary' : true  }  }  ]  }" sleep 5 done done 

“Too many open files”

發現日志中大量出現這個錯誤

執行

curl http://localhost:9200/_nodes/process\?pretty

可以看到

"max_file_descriptors" : 4096,

官方文檔中

Make sure to increase the number of open files descriptors on the machine (or for the user running elasticsearch). Setting it to 32k or even 64k is recommended.

而此時, 可以在系統級做修改, 然后全局生效

最簡單的做法, 在bin/elasticsearch文件開始的位置加入

ulimit -n 64000

然后重啟es, 再次查詢看到

"max_file_descriptors" : 64000,

問題解決