跨集群复制(CCR)

复制经常被采用的策略：从translog拿到更新的历史，把它放到queue里面，然后拿到远程集群去重放所有的action，以达到回放的目的。
同样的ccr工程团队也是优先考虑回放translog，但是很快意识到lucene的translog不能实现快速高效的复制，尝试在translog上增加新的data structures把数据更新动作记录下来，但是lucene是关键的组件涉及复杂的修改，会对整体性能和稳定性有影响。
ccr工程团队尽量采用简单地实现认为功能的实现内置到lucece根基，不应该通过外围的方式实现，
首先lucece只有insert和delete，updata是标记为删除，并且insert一条新的数据。
复制工作需要的基本条件是需要有一个序列号（sequence ID），对lucene索引的操作都有唯一的序列号，添加seq ID后三个应用的设想：
1.可以获取这个ID以后所有操作的步骤；
2.可以快速恢复，集群如果挂了会在别的节点拷贝segment但是耗时长；可以选择translog重放指定seq ID之后的动作；
3.跨集群复制；

Sequence ID

seq ID的添加相当于彻底重写了数据复制逻辑。
1.实现seq ID仅仅seqno是不够的，为什么？
其实给每一个操作加一个seq no远不够，因为es是一个分布式的系统，seqno一定是主分片（primary）负责更新的，因为es所有的写动作一定是先在主分片中verify确认写的有效性，然后在并发在所有副分片同时执行并且等待所有的动作都comfirm后才返回客户端。所以所有的操作是先发生在主分片，如果主分片挂了，副分片提升为主分片，当并发读写很大或者网络分割切换主分片容易出现：原主分片还有残留地读写，新主分片也在读写那么两个分片上生成一样的seqno，这就会在恢复的时候发生冲突，如何处理这种情况？sequence ID = _seq_no + _primary_term，如果出现了主分片的切换，term的值会+1，term可以在cluster stat里面查看，也可在写入数据会返回term值。网络割裂的时候可以通过seq ID获取对应的操作，是存储在lucece文件中，具体指docvalue中。

curl -k -vv -XPOST "https://{ip:port}/foo/doc?pretty" -H 'Content-Type: application/json' --cacert /cert/root-ca.pem --key /cert/{ip}.key.pem --cert /cert/{ip}.crt -d'{"bar" : "baz"}'

查询结果如下：

当有seq ID，下一步是标记现在的操作做到哪一步，引入两个标志位local checkpoint和global checkpoint。
local checkpoint 是指在shard内部操作的标志位，代表这个数字之前的所以操作在这个shards内部操作成功，即成功落盘。
对于一个集群每个数据有多个副本，global checkpoint 代表这个number以前的所有操作在主分片和副分片中都执行成功的，是由primary shards负责更新，包括seqID也是由primary shards负责生成，在副本向主分片确认任何一笔写操作时，都会返回local checkpoint给主分片，因为主分片需要知道副分片哪些已经写成功了，主分片会汇总所有副本上游标位置来确定是否更新global checkpoint。

如此快速恢复不需要比较所有的操作，只要回放最近的global checkpoint以后的操作，提供了非常明显的界限。global checkpoint以前的操作是所有副本确认生效的，回放游标以后的操作。
但是并非所有的恢复都会回放operation 重做只针对于分片落后比较小。如果分片已经断线很久和别的分片差别很大回放耗时时间长，会直接拷贝segment。

Soft delete

lucene原来是怎么delete文档的？

通过标志位，segment刷到磁盘是不会改变的，删除文档只是在另外文件中添加删除标记，这个文件只有在段合并的时候会读那些文档已经被逻辑删除，然后在磁盘中删除相应segment merge生成更大的segment文件。
标记删除后merge真正的删除称为hard delete，因为收到merge干扰。

为了实现跨集群复制，引入soft delete。
所有删除的操作在复制到远端的集群前是不可以被merge删除segment的，否则远端集群会缺少一个删除的动作。
为此，用软删除去保存在Lucene的删除操作，以便用于重放。即：lucene 可以标记一个字段为soft delete，不会被merge删除，直到操作被完整成复制到远端集群时，soft delete转变为原来lucene delete之后merge删除。
那么这个soft delete会维持多久，什么时候可以被真正删除？
复制到远端集群，如果远端集群的通讯断了，游标一直保持在原来的位置会导致soft delete的文档越来越多，后续操作都不能merge 删除，对查询效率有影响。为控制无限制的增长，引入retention lease 代表如果soft delete多长时间内是有效的，超过retention lease 时间soft delete标记被删除，段合并后被删除。

CCR 复制流程

1.以索引为单位建立follow拉取；
2.一对多复制，支持多个cluster同时follow一个索引；
3.follow是单向、主从机制：复制过程中，leader index支持增删改，follow index只读。

CCR通讯链路上的复制

简单来说采用long pull机制由follow index拉取，由远端集群发送请求给主集群，主集群检查是否有operation需要发给客户端，如果需要会立即响应并持续不断的发给客户端。如果没有需要同步的数据，server端会在timeout时间内把连接block住，没有断开连接，并且在这段时间内反复检查是否有数据发送，最后回包给客户端，客户端收到回包立即发出下一个请求。

微观结构分析

以索引为单位建立follow，一个索引有多个分片，微观上是shard为单位建立follow，所以主从索引的分片一致。
seq ID和soft delete是lucene的机制，一个shard是完整的lucene数据结构。
如图，retention lease2标记坐标的操作都已经被复制，可以被merge删除，注意：有N个远端集群对应有N个retention lease。所以lucene merge删除时会选择最小lease 之前的segment可删除，由主分片维护retention lease。

复制流程

初始阶段（initialize stage）
为提升效率，初始阶段会把主集群的segment以文件拷贝的形式拷贝到远端集群，当initialize stage结束后进入到follow stage。
follow stage
这阶段会把operation拿到远端重放，加快同步速度。
pause follow
pause follow时，主分片会记住retention lease的状态和游标位置，还有一种情况网络中断，连接重试直至retention lease超时，retention lease一旦失效两个索引不可能再同步因为部分segment已经被merge删除，有些操作无法追踪。
unfollw
unfollow之后还能被重新follow，之前的segment也会被merge删除，需要重新intialize

主数据中心挂了，将follow index变成 leader index。现阶段seqID业务冲突难处理，segment拷贝会导致恢复速度并不很快

#pause replication
post /<follow_index>/_ccr/pause_follow
#close index
post /<leader_index>/_ccr/pause_follow
#unfollow
post /<follow_index>/_ccr/unfollow
#open the index
post /<leader_index>/_ccr/open

双向复制场景

6 创建auto follow

 curl -k -vv -XPUT "https://{ip:port}/_ccr/auto_follow/beats"  --cacert /cert/root-ca.pem --key /cert/{ip}.key.pem --cert/cert/{ip}.crt -d'{"remote_cluster" : "lqt_index","leader_index_patterns" : ["lqt_*","wx_bill_*"],"follow_index_pattern":"{{leader_index}}-copy"}'