Elasticsearch 数据恢复 unsigned shards

一场源于服务器迁移的数据灾难

正常的数据迁移可能使用备份导入导出的方式，我偏偏选择了虚机的硬盘全盘更换，由于采用docker部署，所以数据迁移搞得有些肆无忌惮。由于新建节点上有一个节点有以前的同名index（这也是个大坑，以后再详细讲），导致冲突，同名index删除后，一切正常的Shards 在新的机器上丢了2组，Cluster 状态变成Red。开源软件就是出现问题抓瞎，全靠google和自己折腾，不然原厂怎么卖服务挣钱呢？这个问题google也没有啊，我得发个英文版出来。

围绕该问题的各种探索，都说最美的风景在路上，现在回味起来都是满满的心流

网上总结了多种原因 ，我觉得最相关的是allocation。

• allocation的官方命令 就是强制让ES去传送一遍数据，结果提示源文件没有找到。
• allocation/explain 这个工具不错，列出了全部节点上的shard分布状态和失败的原因。 发现indices文件都在，就是不能识别。跑到对应的data目录下，查看文件大小全部正常。
• 希望删除unsigned shard ，没有找到官方的办法。
  -查询发现已经正常的shard上的数据仍然可读，通过外部程序重新reindex一遍，结果仍然提示id 对应的shard 没有找到。

最终解决

经过前面的折腾，基本明白：既然数据都在，只是数据同步出现了问题，那就随便指定一个副本吧，大不了就重新导数据。下面列出

//查找原因
GET /_cluster/allocation/explain
{
  "index": "indexname",
  "shard": 2,
  "primary": true
}
//强制指定shard文件来源
POST /_cluster/reroute
{
    "commands" : [
        {
            "allocate_stale_primary" : {
                "index" : "indexname", "shard" : 2,
                "node" : "Frt1jHV",
                "accept_data_loss" : true
            }
        }
    ]
}

总结

数据备份非常重要，其实在动手前可以做磁盘快照，日常可以做备份节点。