1.背景&问题描述
接上篇文章 http://www.jianshu.com/p/329b9f92ac4c
在上一篇文章中，由于系统宕机，导致大量索引出现了Unassigned 状态。在上一篇文章中，我们通过reroute API进行了操作，对主分片缺失的索引，经过上述操作之后，分配了主分片。但是在接下来的操作中，对于副本分片，reroute出错！
如下是索引 alarm-2017.08.12，第0个分片的副本没有分配：
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
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。
