TiKV region merge如何解决故障或隔离的问题？

🪐 TiDB 技术问题
,
1

看了https://pingcap.com/zh/blog/tikv-source-code-reading-21 关于Merge的源码解析博客，有一个问题没有弄清楚。

我目前理解，source peer需要在PrepareMerge日志进入Apply之后，才会向本地的target peer发起CommitMerge请求，然后不断通过merge tick推动target完成合并；target peer本身并不会主动向source peer发送消息补全日志。

那么假设有一个source peer，在多数派Apply PrepareMerge之前它就挂掉了甚至没收到PrepareMerge的日志；那么多数派都进入了CommitMerge阶段，并且完成了Merge、删除对应store上的source peer之后，这个孤立的节点重启，这时它是如何追上merge过程的呢？如果它日志里没有包含PrepareMerge，那么它也就不会向本地target peer发起merge tick，虽然本地source peer持有它所需的日志，但是source peer又不会主动补全它缺失的部分？具体的实现是怎么做的呢？

2

假设每个Region一旦完成merge之后，对应的source peer就进入Tombstone状态；但是否此时Leader仍然处于Offline状态，会继续向 peer 同步日志？这样当隔离节点恢复时，它依然能够补全日志并且进入PrepareMerge以及之后的CommitMerge阶段。

当所有Tombstone状态的节点日志都完全同步之后，Leader才销毁自己，彻底完成Merge过程；Non-Leader就不用等直接销毁了。这样的思路合理吗？

3
  1. region 本身追赶 raft log 是有时限要求的，若超过时限，则无法通过 raft log进行追赶了，只能通过 snapshot 进行重放
  2. region 的合并依然受 key 区间的影响，左闭，右开 [1,100+) 这种方式，会选择 key区间能够相容的 region进行合并
  3. region 副本是需要和 region leader 之间保持心跳的，期间也会传递水位线来保持 raft log 的平衡点
  4. 合并是通过 PD 来调度的，region 的状态信息均由 PD 来掌控

参考下图：

image
image993×905 47.3 KB

另外可以参考文档：

4

我个人感觉关于Merge的博客在介绍完Merge流程之后，关于隔离恢复、对Raft影响这些部分介绍很不清楚，甚至文字流畅性都有些问题，几乎读不出来他想说什么、或者想表达什么问题；所以才来提问

1 个赞
5

文章在于引入，至于领会多少都在个人

你有兴趣的话，可以阅读下源码，研究下～ 也欢迎投稿～ :love_you_gesture: