0x01 缘由

产品开发过程中没有专人去深入理解elasticsearch相关原理，导致在产品生产部署时，没有做到合理的物理架构部署，导致后期问题不断出现。

当外场出现服务器资源瓶颈时，紧急调整相关结构，忙中出错，调整主节点时，导致某个索引无法找回相关分片。类似：

1、3分片 “ UNASSIGNED”

0x02 场景描述

软件：elasticsearch 5.1.1 版本 5个节点 1个主节点

运行软件：上面跑各种程序，导致资源使用需要非常珍惜。

a.尝试修改elasticsearch/config/elasticsearch.yml 中相关参数，即作为数据节点，又作为主节点如下：

node.master: true

node.data: true

b.重启es

重启es几分钟后，重新分片还未完成，就开始重启其他节点。

c.过了几个小时后，发现一个索引分片无法找回，状态变为RED；

后台日志报错：

017-08-31T15:37:06,018][WARN ][o.e.g.DanglingIndicesState] [node8] [[wide_protocols_215a_201707/j7yRa0RoT6eQPZzl67wv3g]] can not be importe

d as a dangling index, as index with same name already exists in cluster metadata

数据对于现网运行环境来说，比较重要。所以得想办法去恢复索引分片。

a.查看索引分片的uuuid:

b.然后进入后台数据存储路径，查看，发现7月份索引两个分片信息，这也是导致es后台日志有如下警告的原因：

017-08-31T15:37:06,018][WARN ][o.e.g.DanglingIndicesState] [node8] [[wide_protocols_215a_201707/j7yRa0RoT6eQPZzl67wv3g]] can not be importe

d as a dangling index, as index with same name already exists in cluster metadata

c.导致es状态总是 RED，影响到数据的检索速度等。

解决问题的过程中尝试了很多做法：

1、强制重新分片---无用

2、尝试修改分片文件信息---无用

最后，可行的方法是：

1、将所有节点新生成的UUID对象的文件备份移走；

2、通过head等工具，直接删除该索引；

3、ES立马把老的索引信息恢复；

解决问题是一个逻辑推理的过程，只有根据相关信息和理论去找原因，然后不断在开发环境下尝试，最后总会找到解决问题的方法。