从全局看，14:30 出现 lag。
- Owner 维护全局的同步状态，更新所有 changefeed 的全局 CheckpointTs 和 ResolvedTs；
- Processor 根据全局 ResolvedTs 推进自己节点的数据向下游同步；即：全局的 ResolvedTs 落后导致 Processor 的 checkpointTs 落后；
- 一般而言，各组件的 checkpointTs 在未出现异常状态下，就是组件自己负责的最后一个 ResolvedTs；
- 本例中，最小的 Processor CheckpointTs 是 IP 222 的 14:30:16；
- 虽然 IP 222 的 Table reslovedTs （接收的最新数据时间戳）达到了 17:59:56.772 但自身并没有写下 checkpointTs 而是维持在 17:30:12.872 ，证明在 17:30:12.872 ～ 17:59:56.772 之间 IP 222 的 Processor 认为存在部分数据未从 TiKV 发送给 Capture。
综上，CDC 由于 Processor 的 checkpointTs 未推进而迟迟未向下游同步。至于为什么 Processor 这么认为从日志中没找到可以突破的点。可以尝试缩容下 IP 222 的 Capture，让 processor 重新调度到 IP 223 看看是否可以绕过该问题。
