背景
客户磁盘损坏，修复磁盘后，重启机器，发现elasticsearch启动成功，ES状态正常green，但是历史数据都没有加载进，查看ES存储数据目录，发现数据还在。
解决方案
- 首先，需要确认indices目录下的lucene 索引正常。需要关闭ES（实际操作索引处于close状态也可以）。
# 检测lucene 索引数据是否正常
java -cp /usr/share/elasticsearch/lib/*:/usr/share/elasticsearch/lib/elasticsearch-*.jar -ea:org.apache.lucene... org.apache.lucene.index.CheckIndex 文件路径
如果返回java异常报错，注意文件路径，需要到index分片目录下，例如：
/data/elasticsearch/data/nodes/0/indices/LV3R8lK_RU6RJyQlYIx6Tw/0/index/
如果CheckIndex检测到问题并且其修复建议看起来很明智，使用 -exorcise 命令修复
# 修复lucene数据
java -cp /usr/share/elasticsearch/lib/*:/usr/share/elasticsearch/lib/elasticsearch-*.jar -ea:org.apache.lucene... org.apache.lucene.index.CheckIndex -exorcise 文件路径
- 其次，查看索引分片具体的失败原因
使用如下API查看
# 查看分片分配失败原因
curl -XGET IP:9200/_cluster/allocation/explain?pretty
或者，查看es的日志，也会打印出堆栈信息，分片分配失败原因。
-
如果，报错_state目录下的.st文件损坏 则删除这个问题，然后重新分配
3.1 手动重新分配
# 手动重新分配
curl -XPOST IP:9200/_cluster/reroute?retry_failed=true
3.2 手动分配陈腐的分片
# 手动分配陈腐的分片
curl -H "Content-Type:application/json" -XPOST "localhost:9200/_cluster/reroute?pretty" -d '
{
"commands": [
{
"allocate_stale_primary": {
"index": "{索引名称}",
"shard": "{分片ID}",
"node": "{节点名称}",
"accept_data_loss": true
}
}
]
}'
需要从步骤2 查看分片分配失败原因的返回结果中，选取index 、shard、node信息
-
如果报错translog-*.tlog日志文件损坏，那么需要移走这个tlog日志文件，然后重试3.2步骤，手动分配陈腐的分片。
此种情况会丢失损坏的tlog文件中的数据。但相对整个索引丢失，已经是最好的情况了
-
如果在索引的分片数据目录，出现corrupt开头的文件，则需要清理掉这个文件。corrupt开头的文件是记录文件损坏的位置，不移除这个文件，分配stale是无法恢复，移除了这个文件才能恢复。清理完corrupt文件之后，再重试 3.2 手动分配陈腐的分片
-
如果尝试以上种种，都不能恢复分片数据。那么为了保证当前索引的正常业务的读写以及ES正常的状态。只能重建索引。丢失的数据不要了（最糟糕的情况）。
# 丢弃分片，保留索引
curl -H "Content-Type:application/json" -XPOST "IP:9200/_cluster/reroute?pretty" -d '
{
"commands": [
{
"allocate_empty_primary": {
"index": "{索引名称}",
"shard": "{分片ID}",
"node": "{节点名称}",
"accept_data_loss": true
}
}
]
}'
批量修复分片，不要数据了
