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
0x03 问题分析
数据对于现网运行环境来说，比较重要。所以得想办法去恢复索引分片。 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，影响到数据的检索速度等。
0x04 解决思路和办法
解决问题的过程中尝试了很多做法： 1、强制重新分片---无用 2、尝试修改分片文件信息---无用 最后，可行的方法是： 1、将所有节点新生成的UUID对象的文件备份移走； 2、通过head等工具，直接删除该索引； 3、ES立马把老的索引信息恢复；
0x05 总结
解决问题是一个逻辑推理的过程，只有根据相关信息和理论去找原因，然后不断在开发环境下尝试，最后总会找到解决问题的方法。