这个问题我测试了很多次，一直没有一个明确的答案。
出现的结果飘忽不固定，让人迷惑。(ES7.10.x)
a,b两个节占，索引x (都是缺省配置，没啥特别的）
a是master，上面是主分片，b节点上副分片。
写入数据1111
这时b节点crash了(是crash，不是正常关闭！）
这里写入2222（因为a还在，所以可以正常写）
flush一下，再写入3333
这个时候，把节点b启动起来。完成恢复后，b上面的肯定有完整的所有数据。
副分片恢复中，有“日志恢复”这一个过程，
问题是：由a发给b的日志中，包括1111,2222,3333中的哪些数据？
图片与主题无关：
出现的结果飘忽不固定，让人迷惑。(ES7.10.x)
a,b两个节占，索引x (都是缺省配置，没啥特别的）
a是master，上面是主分片，b节点上副分片。
写入数据1111
这时b节点crash了(是crash，不是正常关闭！）
这里写入2222（因为a还在，所以可以正常写）
flush一下，再写入3333
这个时候，把节点b启动起来。完成恢复后，b上面的肯定有完整的所有数据。
副分片恢复中，有“日志恢复”这一个过程，
问题是：由a发给b的日志中，包括1111,2222,3333中的哪些数据？
图片与主题无关：
3 个回复
charlesfang
赞同来自:
两种方式的数据内容其实是一样，如下：
index操作：id, type, seq_no, primary_term, version, source, routing
delete操作：id, type, seq_no, primary_term, version
soft_delete机制读取lucene history retention 操作代码
Charele - Cisco4321
赞同来自:
租约有效期是12小时，测试时，不可能因为是超时的原因吧。
"过了租期"是租约无效的原因之一，还有没有其它可能租约无效呢？？？
Charele - Cisco4321
赞同来自:
估计是这个原因，但没找到根原是什么。
peer恢复时，有两种选项，SN恢复和非SN
要5个判断全部为真时才会SN
A SN情况：所有缺失的都形成日志来回放，包括上面场景中2222
B 非SN:
就像你说的那样，“回放操作完成不了恢复，需要通过拷贝索引文件完成恢复”，
数据2222要通过拷贝索引文件（因为已经flush过了，有文件）
问题是：有时候，这个租约会丢失，图中第4个条件：蓝色条件不满足，
(可以确定前面3个条件肯定是true)
没想到上面场景中，租约丢失的原因。PS:肯定不可能是超时