想请问一下大佬们，TiCDC 订阅一张表（test_table），应该是订阅 test_table 所在的 region，但是后续 region 可能会 split 和 merge，那 TiCDC 怎么感知到 test_table 需要新增或者删除 region 呢？
大概过程 split merge会产生raft消息，cdc就是监控region上的raft消息
猜测是不是可通过 Region 的 epoch 信息来判断？
在 Region 的 epoch 里，有 conf_ver 和 version，分别表示这个 Region 不同的版本状态。若一个 Region 发生了 membership changes，即新增或删除了 peer，conf_ver 会加 1，若 Region 发生了 split 或者 merge，则 version 加 1。因此，可通过 epoch 信息来判断 Region 的新增、删除与分裂、合并。
cdc 检测到了 split、merge后，需要添加新的 region 进来，那这个 region client 的启动时间怎么把握呢？raft消息里会明确 region 是在哪个时间点 split、merge 吗？或者我理解的不对，还望大佬解答。
…, 但是后续 region 可能会 split 和 merge，那 TiCDC 怎么感知到 test_table 需要新增或者删除 region 呢？
TiCDC 在内存中维护了监听的数据范围，根据范围去监听对应 region。如果 region 发生 split/merge，该 region 会把相应的信息同步给 TiCDC，TiCDC 根据信息去监听新的 region。
…, 那这个 region client 的启动时间怎么把握呢？raft消息里会明确 region 是在哪个时间点 split、merge 吗？或者我理解的不对，还望大佬解答。
在 TiCDC 发起 regoin 监听请求时会带上当前时刻的 checkpoint ts，TiKV 收到请求后进行增量扫把 (checkpoint ts, current ts] 历史增量数据同步给 TiCDC，同时也会把实时数据同步给 TiCDC。
在 TiCDC 发起 regoin 监听请求时会带上当前时刻的 checkpoint ts
这个 checkpoint ts 是在哪里维护的呢？
Checkpoint ts 在 TiCDC 内存中维护，也会持久化到 PD 中。
TiCDC 每次获取到数据时，都会推进 checkpoint ts嘛？还是说有专门的 ts event 呢？
Checkpoint ts 的推进看 TiCDC 同步到下游的进度，然后再定时持久化 checkpoint ts 。
此话题已在最后回复的 60 天后被自动关闭。不再允许新回复。