为什么ES的副本分片进行恢复的时候，仅仅向主分片提供_seq_no就可以了，拿到主分片_seq_no后的操作就算恢复完成，而不是提供_seq_no+_primary_term

感觉仅仅提供_seq_no是有问题的，会造成主分片和副本分片的数据不一致。举个例子现在有三个节点，node0是主节点，node1和node2是数据节点，有一个索引(test_index),主分片在node1上，副本分片在node2上，translog采用的是async的方式，现在写入一个为{"data": "A"}的document。此时这个document会写入到node1和node2的分片上面，并且会给文档分配一个seqNo(假设是1)。会不会存在这种情况node1上的主分片没有flush也没有translog，而node2上的副本分片进行了flush和translog。此时node1和node2突然宕机，然后node1先启动，由于没有flush和translog，所以{"data": "A"}的document会丢失，然后再写入一个为{"data": "B"}的document(此时这个seqNo也是1)。而node2启动的时候，会根据下面的代码获得从seqNo+1开始恢复(根据本案例seqNo+1=2)，那么seqNo为1的数据在node1节点是{"data": "B"}，在node2节点是{"data": "A"}，这样将造成主分片与副本分片不一致
 
我看的是ES7.0的源码
org.elasticsearch.indices.recovery.PeerRecoveryTargetService#getStartingSeqNo

 
我看了这个内容github.com/elastic/elasticsearch/pull/43205，感觉与我说的问题有点关联，是不是在ES7.3之后就不存在这个问题了
类似的我看kafka曾经也遇到过此类问题cwiki.apache.org/confluence/display/KAFKA/KIP-101+-+Alter+Replication+Protocol+to+use+Leader+Epoch+rather+than+High+Watermark+for+Truncation
Kafka就是采用leader+offset的方式