【ES实战】ES主副分片数据不一致分析

ES主副分片数据不一致分析

问题描述

在请求索引中的某一条数据时，时而查询有结果，时而无结果。两种情况交替出现。

问题重现

通过对问题数据的点查，确实重现了该现象

GET indexName/typename/docid
1

问题分析

按照ES写入的设计，是最终一致性的，在进行刷盘之后，应该是不会丢失的。存储物理文件的损坏，应该是引起索引的不健康或者集群的不健康。

ES的底层使用的是Lucene，所以详细分析了对应版本的Lucene物理文件。

下表总结了 Lucene 中文件的名称和扩展名：

由于使用的不同，并非每个索引下都同时出现以上后缀名的文件。

对副本分片的物理文件进行破坏。

若进行大规模破坏，在下次刷盘时，会触发修复，重新分配分片。

若进行轻微破坏，比如打开下面的文件，轻微删除某条记录。不会被ES感知。集群和索引状态均显示正常。

GET gudong20231012/_doc/igntIYsBVSH_ahC4Fj7-
1

出现了副本数据查不到，主分片数据可以查询的现象。

判断应该是数据的物理文件出现了损坏，导致数据读不出来了。

修复方案

以当前主分片的数据为准，对副本分片进行重建。重建后的副本会自动获取全部最新的主分片的数据，若此时还是查询不到数据，那么只有重新向ES写入数据了。

先删除副本分片在增加副本。

PUT gudong20231012/_settings
{
 "number_of_replicas": 0
}
1
2
3
4

PUT gudong20231012/_settings
{
 "number_of_replicas": 1
}
1
2
3
4