解决elasticsearch集群Unassigned Shards 无法reroute的问题

1.背景&问题描述

接上篇文章 http://www.jianshu.com/p/329b9f92ac4c
在上一篇文章中,由于系统宕机,导致大量索引出现了Unassigned 状态。在上一篇文章中,我们通过reroute API进行了操作,对主分片缺失的索引,经过上述操作之后,分配了主分片。但是在接下来的操作中,对于副本分片,reroute出错!
如下是索引 alarm-2017.08.12,第0个分片的副本没有分配:

解决elasticsearch集群Unassigned Shards 无法reroute的问题_第1张图片
Paste_Image.png

下面执行语句:

  POST /_cluster/reroute
  {
  "commands": [
    {
      "allocate_replica": {
        "index": "alarm-2017.08.12",
        "shard": 0,
        "node": "node4-1"
      }
    }
  ]
}

结果执行失败!

{
  "error": {
    "root_cause": [
      {
        "type": "remote_transport_exception",
        "reason": "[node3-2][192.168.21.88:9301][cluster:admin/reroute]"
      }
    ],
    "type": "illegal_argument_exception",
    "reason": "[allocate_replica] allocation of [alarm-2017.08.12][0] on node {node4-1}{u47KtJGgQw60T_xm9hmepw}{UbaCHI4KRveQeTAnJvGFEQ}{192.168.21.89}{192.168.21.89:9301}{rack=r4, ml.enabled=true} is not allowed, reason: [NO(shard has exceeded the maximum number of retries [5] on failed allocation attempts - manually call [/_cluster/reroute?retry_failed=true] to retry, [unassigned_info[[reason=ALLOCATION_FAILED], at[2017-08-16T00:54:47.088Z], failed_attempts[5], delayed=false, details[failed recovery, failure RecoveryFailedException[[alarm-2017.08.12][0]: Recovery failed from {node8}{Bpd3y--EQsag1u1NTmtZfA}{4T_McpmjSXqLowRoXztssQ}{192.168.21.89}{192.168.21.89:9301}{rack=r4} into {node5}{i4oG4VcaSdKVeNEvStXwAw}{w4nAITEOR9u7liR55qDsVA}{192.168.21.88}{192.168.21.88:9300}{rack=r3}]; nested: RemoteTransportException[[node8][192.168.21.89:9301][internal:index/shard/recovery/start_recovery]]; nested: RecoveryEngineException[Phase[1] phase1 failed]; nested: RecoverFilesRecoveryException[Failed to transfer [0] files with total size of [0b]]; nested: FileSystemException[/opt/elasticsearch/elasticsearch-node8/data/nodes/0/indices/FgLdgYTmTfazlP8i5K0Knw/0/index: Too many open files in system]; ], allocation_status[no_attempt]]])][YES(primary shard for this replica is already active)][YES(explicitly ignoring any disabling of allocation due to manual allocation commands via the reroute API)][YES(target node version [5.5.1] is the same or newer than source node version [5.5.1])][YES(the shard is not being snapshotted)][YES(node passes include/exclude/require filters)][YES(the shard does not exist on the same host)][YES(enough disk for shard on node, free: [6.4tb], shard size: [0b], free after allocating shard: [6.4tb])][YES(below shard recovery limit of outgoing: [0 < 2] incoming: [0 < 2])][YES(total shard limits are disabled: [index: -1, cluster: -1] <= 0)][YES(allocation awareness is not enabled, set cluster setting [cluster.routing.allocation.awareness.attributes] to enable it)]"
  },
  "status": 400
}

注意看错误:

FileSystemException[/opt/elasticsearch/elasticsearch-node8/data/nodes/0/indices/FgLdgYTmTfazlP8i5K0Knw/0/index: Too many open files in system

2.问题分析:

表面上看好像是还是超出了文件limits。但是在做上述操作的过程中,我已经将所有配置调整,并将elasticsearch集群升级,新增了两台服务器,将服务器修改为如下节点:

节点名称 服务器 http端口 rack Xms&Xmx
node1-1 192.168.21.23 9201 rack1 20G
node1-2 192.168.21.23 9202 rack1 20G
node1-3 192.168.21.23 9203 rack1 20G
node2-1 192.168.21.24 9201 rack2 20G
node2-2 192.168.21.24 9202 rack2 20G
node2-3 192.168.21.24 9203 rack2 20G
node3-1 192.168.21.88 9201 rack3 20G
node3-2 192.168.21.88 9202 rack3 20G
node3-3 192.168.21.88 9203 rack3 20G
node4-1 192.168.21.89 9201 rack4 20G
node4-2 192.168.21.89 9202 rack4 20G
node4-3 192.168.21.89 9203 rack4 20G

但是报错日志中还是node8,这证明可能是上次宕机直接导致了副本文件不可用,无法进行reroute.
现在查看各节点的limits配置:

GET _nodes/stats/process?filter_path=**.max_file_descriptors

结果:

{
  "nodes": {
    "57A1rYqMRH-igOdlM9VyRg": {
      "process": {
        "max_file_descriptors": 655350
      }
    },
    "if6AS6S-REKMOOVAp__xkg": {
      "process": {
        "max_file_descriptors": 655350
      }
    },
    "Q4iPvXjvQkK6OImAHisHcw": {
      "process": {
        "max_file_descriptors": 655350
      }
    },
    "VTqaCdj6TEGjDN5dlsygVw": {
      "process": {
        "max_file_descriptors": 655350
      }
    },
    "u47KtJGgQw60T_xm9hmepw": {
      "process": {
        "max_file_descriptors": 655350
      }
    },
    "Bpd3y--EQsag1u1NTmtZfA": {
      "process": {
        "max_file_descriptors": 655350
      }
    },
    "i4oG4VcaSdKVeNEvStXwAw": {
      "process": {
        "max_file_descriptors": 655350
      }
    },
    "pYKjqz0hS3aSs8sBuZbfFg": {
      "process": {
        "max_file_descriptors": 655350
      }
    },
    "mSyzxBFFTRmLx4TWaPpJYg": {
      "process": {
        "max_file_descriptors": 655350
      }
    },
    "8_cG1N_cSY-VfQLK-zVuhQ": {
      "process": {
        "max_file_descriptors": 655350
      }
    },
    "JIKzocuZRtec_XkrM1eXDg": {
      "process": {
        "max_file_descriptors": 655350
      }
    },
    "Ol6mvLtURTu5Ie6bX_gSdQ": {
      "process": {
        "max_file_descriptors": 655350
      }
    }
  }
}

可以看到每个节点的max_file_descriptors都非常大,不太可能出现无法打开文件的错误,这只有一种可能,就是原来的副本分片数据存在问题,无法reroute。
副本无法reroute!!!
想了各种办法之后,决定用以下两种方式来解决:
方法一:我想到了将索引snapshot到文件系统,之后再restore 。
但是这个方案再尝试了一个索引之后放弃。因为elasticsearch的snapshot需要每个节点的snapshot目录通过NFS方式实现网络共享。也就是类似与windows的共享文件夹。这样来保证所有节点的备份都导出到同一个目录。这个方案被放弃的原因是nfs共享目录还没有建立,而且这个过程比较复杂。如果有更好的办法肯定放弃这个方案。
方法二:有没有一种简单的办法让索引重建?我查看了elasticsearch的官方文档。终于找到了reindex。对就是这个功能强大的reindex。
https://www.elastic.co/guide/en/elasticsearch/reference/current/docs-reindex.html
具体参数可参考上述链接。这个reindex不仅可以让本地索引重建,而且还可以以其他elasticsearch服务器为源重建索引。也就是说可以将其他集群的索引拷贝到目标集群。
补充:
方法三:还有一种更为快捷的办法,考虑到elasticsearch的分片的副本可以动态的设置,那么其实可以先将 number_of_replicas 设为0,待副本分片都删除之后,再将number_of_replicas改为1,这样副本分片就会自动恢复。同时,考虑到副本的优化情况,建议在做该操作的同时,做一次段合并。以节约空间和减少文件句柄数。

3.reindex解决过程

选择了目标索引
alarm-2017.08.12


解决elasticsearch集群Unassigned Shards 无法reroute的问题_第2张图片
Paste_Image.png
  POST /_reindex
  {
    "source": {
      "index": "alarm-2017.08.12"
    }
    , "dest": {
      "index": "alarm-2017.08.12.bak",
      "version_type": "external"
    }
  }

响应结果

{
  "took": 7143,
  "timed_out": false,
  "total": 1414,
  "updated": 0,
  "created": 1414,
  "deleted": 0,
  "batches": 2,
  "version_conflicts": 0,
  "noops": 0,
  "retries": {
    "bulk": 0,
    "search": 0
  },
  "throttled_millis": 0,
  "requests_per_second": -1,
  "throttled_until_millis": 0,
  "failures": []
}

再查看索引监控,发现索引重建成功,分片也正常。

Paste_Image.png

现在只需要将原来的索引删除即可!
如果需要索引名与之前一致,则将现有索引增加一个别名即可。
https://www.elastic.co/guide/cn/elasticsearch/guide/current/index-aliases.html

DELETE alarm-2017.08.12
PUT alarm-2017.08.12.bak/_alias/alarm-2017.08.12

不难发现,在elasticsearch中并没有类似于mysql table那样直接可以修改表名的操作,这可能与elasticsearch的特殊结构有关系。reindex是一个非常重要的操作,在某些方面,甚至可能取代备份的snapshot。直接通过一个新的集群将数据copy。

4.修改number_of_replicas解决过程

选取目标索引
applog-prod-2016.12.18
可以看到存在分片未分配状况:

GET _cat/shards/applog-prod-2016.12.18*

applog-prod-2016.12.18 4 r STARTED    916460 666.4mb 192.168.21.24 node2-2
applog-prod-2016.12.18 4 p STARTED    916460 666.6mb 192.168.21.23 node1-3
applog-prod-2016.12.18 1 p STARTED    916295 672.8mb 192.168.21.88 node3-3
applog-prod-2016.12.18 1 r STARTED    916295 672.8mb 192.168.21.24 node2-3
applog-prod-2016.12.18 2 r STARTED    916730 670.9mb 192.168.21.89 node4-2
applog-prod-2016.12.18 2 p STARTED    916730 670.9mb 192.168.21.23 node1-3
applog-prod-2016.12.18 3 r STARTED    917570 674.9mb 192.168.21.23 node1-1
applog-prod-2016.12.18 3 p STARTED    917570 674.9mb 192.168.21.24 node2-2
applog-prod-2016.12.18 0 p STARTED    917656 673.5mb 192.168.21.88 node3-2
applog-prod-2016.12.18 0 r UNASSIGNED                              

现在修改number_of_replicas

PUT applog-prod-2016.12.18/_settings
{
  "index":{
    "number_of_replicas":0
  }
}

可以看到number_of_replicas变成了0,分片只有1份

GET applog-prod-2016.12.18/_settings
{
  "applog-prod-2016.12.18": {
    "settings": {
      "index": {
        "refresh_interval": "5s",
        "number_of_shards": "5",
        "provided_name": "applog-prod-2016.12.18",
        "creation_date": "1482019342621",
        "number_of_replicas": "0",
        "uuid": "hmZfjW80Q-SeV_qha_r-EA",
        "version": {
          "created": "5000199"
        }
      }
    }
  }
}

分片:

GET _cat/shards/applog-prod-2016.12.18*
applog-prod-2016.12.18 4 p STARTED 916460 666.6mb 192.168.21.23 node1-3
applog-prod-2016.12.18 1 p STARTED 916295 672.8mb 192.168.21.88 node3-3
applog-prod-2016.12.18 2 p STARTED 916730 670.9mb 192.168.21.23 node1-3
applog-prod-2016.12.18 3 p STARTED 917570 674.9mb 192.168.21.24 node2-2
applog-prod-2016.12.18 0 p STARTED 917656 673.5mb 192.168.21.88 node3-2

对段进行合并:

POST /applog-prod-2016.12.18/_forcemerge?max_num_segments=1

之后再将number_of_replicas改回来

PUT applog-prod-2016.12.18/_settings
{
  "index":{
    "number_of_replicas":1
  }
}

分片情况:

GET _cat/shards/applog-prod-2016.12.18*
applog-prod-2016.12.18 4 r INITIALIZING                192.168.21.89 node4-1
applog-prod-2016.12.18 4 p STARTED      916460 666.6mb 192.168.21.23 node1-3
applog-prod-2016.12.18 1 p STARTED      916295 672.8mb 192.168.21.88 node3-3
applog-prod-2016.12.18 1 r INITIALIZING                192.168.21.89 node4-3
applog-prod-2016.12.18 2 r STARTED      916730 670.9mb 192.168.21.89 node4-1
applog-prod-2016.12.18 2 p STARTED      916730 670.9mb 192.168.21.23 node1-3
applog-prod-2016.12.18 3 r STARTED      917570 674.9mb 192.168.21.89 node4-3
applog-prod-2016.12.18 3 p STARTED      917570 674.9mb 192.168.21.24 node2-2
applog-prod-2016.12.18 0 p STARTED      917656 673.5mb 192.168.21.88 node3-2
applog-prod-2016.12.18 0 r INITIALIZING                192.168.21.89 node4-1

可以发现分片会被初始化,恢复到2个分片。

5.总结

对于索引出现Unassigned 的情况,最好的解决办法是reroute,如果不能reroute,则考虑重建分片,通过number_of_replicas的修改进行恢复。如果上述两种情况都不能恢复,则考虑reindex。

你可能感兴趣的:(解决elasticsearch集群Unassigned Shards 无法reroute的问题)