软件版本: es 6.5.4，有xpack插件
运行环境: es集群有3个节点：node1，node3，node4, 参数配置基本都是默认配置。集群、节点、索引分片等的健康状态都是green。smas_email索引设置为6个分片,2个副本.其中,mailId字段定义为
es数据写入是采用10个线程并发写入，每个线程一次共大概会写1000条左右的文档数据，每天写1到5次。写入时都默认向node3这个es节点写入。系统运行半年一直是正常的。 直到最近一个月出现下面的问题。
错误现象：
在项目工程中通过http方式反复执行同一个es查询语句,查询最近导入的文档内容,返回结果时有时无. 在kibana中执行es查询语句,现象一样. 对有的mailId来说,返回结果是周期性地1次成功,2次失败,对有的mailId,是周期性地2次成功,1次失败, 对以前很早导入的文档,都能查询成功. 应该不是一致性问题,这个现象10多天来一直存在.
查看es日志，没有看到相应的错误日志。
es查询成功的示例截图
es查询失败的示例截图
在排查过程中也发现几个奇怪的现象.
1、在上面查询语句中增加 ？preference=_primary_first , 会导致查询全部失败.
2、查看索引分片情况. 主分片全部分配在node1 这台服务器上. 另外,两个副本中,1个副本的文档数与主分片一致,另外一个副本的文档数大于主分片文档数.
附件：
smas_email的mapping定义
es配置文件elasticsearch.yml
请教各位大神:
1、这个问题是什么原因导致的？
2、在不重建索引和重新导入数据的情况下，有什么办法能比较稳妥地修复这个问题？
3、如果一定要重建索引，怎么做才能保证从主分片和副本中获取到完整的历史数据？（因为一个副本中的文档数居然比主分片还多不少）
运行环境: es集群有3个节点：node1，node3，node4, 参数配置基本都是默认配置。集群、节点、索引分片等的健康状态都是green。smas_email索引设置为6个分片,2个副本.其中,mailId字段定义为
"mailId":{
"type":"text",
"fields":{
"keyword":{
"type":"keyword",
"ignore_above":256
}
}
}es数据写入是采用10个线程并发写入，每个线程一次共大概会写1000条左右的文档数据，每天写1到5次。写入时都默认向node3这个es节点写入。系统运行半年一直是正常的。 直到最近一个月出现下面的问题。
错误现象：
在项目工程中通过http方式反复执行同一个es查询语句,查询最近导入的文档内容,返回结果时有时无. 在kibana中执行es查询语句,现象一样. 对有的mailId来说,返回结果是周期性地1次成功,2次失败,对有的mailId,是周期性地2次成功,1次失败, 对以前很早导入的文档,都能查询成功. 应该不是一致性问题,这个现象10多天来一直存在.
查看es日志，没有看到相应的错误日志。
es查询成功的示例截图
es查询失败的示例截图
在排查过程中也发现几个奇怪的现象.
1、在上面查询语句中增加 ？preference=_primary_first , 会导致查询全部失败.
2、查看索引分片情况. 主分片全部分配在node1 这台服务器上. 另外,两个副本中,1个副本的文档数与主分片一致,另外一个副本的文档数大于主分片文档数.
附件：
smas_email的mapping定义
es配置文件elasticsearch.yml
请教各位大神:
1、这个问题是什么原因导致的？
2、在不重建索引和重新导入数据的情况下，有什么办法能比较稳妥地修复这个问题？
3、如果一定要重建索引，怎么做才能保证从主分片和副本中获取到完整的历史数据？（因为一个副本中的文档数居然比主分片还多不少）
6 个回复
alex_farm
赞同来自:
chrisxucd123
赞同来自:
pony_maggie - 公众号:犀牛饲养员的技术笔记
赞同来自:
tacsklet - 公司有用到es
赞同来自:
chrisxucd123
赞同来自:
PUT /smas_mailheader/_settings
{
"number_of_replicas": 1
}
这个命令,先把副本数设置为1, 再设置为2. 相当于让es自动重建副本. 但因为有一个副本的文档数比主分片还大,担心减少副本时把这个文档数大的副本给删掉了,就可能导致数据丢失.所有没有这样操作.
redhat
赞同来自: