首先 CheckTxnStatus 一定会写入 protected rollback；然后如果你担心的是截图中的 ResolveLock 的处理里面没有设置 protected rollback 导致晚到的 prewrite 可能成功，理论上确实有可能，且乐观悲观都有可能，但是不影响事务正确性，因为在此之前 CheckTxnStatus 一定是写过 protected rollback 的（更严谨地说，对于普通 2PC 事务，primary 一定在 CheckTxnStatus 中被写入 protected rollback；对于 async commit 事务，则也有可能某个 seconda…

对事务 T 使用 Non-protected rollback 意味着已知事务 T 必定被回滚、不可能有并发的其它东西在尝试提交事务 T；这种情况可能发生在事务自身主动进行 rollback （注意不是 rollback 语句，而是 commit 中途失败之后进入的 rollback）。 对事务 T 使用 Protected rollback，意味着不确定事务 T 是否可能被并发地提交，那么需要保证事务必定被回滚，那么需要保证当前写入的 rollback 信息在任何情况下不可以丢弃；而并发的提交过程看到该 rollback 信息便会失败。这种情况可能发生在事务被另一个事务进行 resolve…

Target Region 在 apply CommitMerge 的时候，epoch version 也递增了，为何避免了 split 类似的问题呢？ CommitMerge apply 成功会导致 epoch 增加，也会有类似 split 的问题。 不过这个我认为不算可用性问题，客户端更新 epoch 信息后重试一下就行了，通常在 10～100ms 之间吧。

可以先看下 TiKV-Details → Threads → Threads IO，定位是哪几个线程在消耗 IO，大致可以看出 TiKV 在做什么操作。 下面是 Threads IO 的例子： [image]

欢迎查看 TiKV CDC 模块的源码阅读博客 TiCDC 源码阅读（二）TiKV CDC 模块介绍 | PingCAP

由于一些技术限制，目前 TiCDC 6.1 最低支持 5.1.0-alpha 的 TiDB 集群。

可能是这个 https://github.com/pingcap/tiflow/issues/4241 总的来说，老版本 TiCDC 中存在当下游 kafka 异常时可能导致 TiCDC 节点卡住的问题，从而影响其他 changefeed。 建议升级 TiCDC 到 6.1 或者 6.5 的最新版本。

图中错误的原因是下游 CDC 提前把链接断开了，是非预期的。java 版本的 CDCClient 没经过大量测试，尚不成熟。 建议使用 TiCDC https://docs.pingcap.com/zh/tidb/stable/ticdc-overview。

表结构和 UPDATE 语句能贴一下吗？是更新了主键吗？

谢谢反馈，这个问题目前需要用 URL encode 来转义下特殊字符，后面会考虑如何优化该问题。

对于跨云（或者跨地区）的同步，推荐以下操作： 将 TiCDC 部署到下游，是 TiCDC 到下游 TiDB 的网络延时进可能低。 打通上下游的网络，使得 TiCDC 能访问到所有 TiKV 和 PD。 这时同步速度上限取决于上下游之间网络的带宽。

麻烦用 kubectl logs -p 采集下 TiCDC Pod 重启前的日志

从监控上看 checkpoint 一直在向前推进，说明有 DDL 在同步中。目前，TiCDC 同步的 DDL 的速度较慢，所以会看到延时上升的情况，一般来说 CREATE TABLE 这种 DDL 单个的同步延时在 0.1～1 秒之间。

你好，可以上传下完整的 TiCDC 监控和所有 TiCDC 节点的日志吗？

该类日志说明 TiCDC 已经接近同步极限，v5 的 TiCDC 同步的表数有限，建议使用 v6.1 LTS 版本，会稳定很多。

TiCDC 不支持同步非 TiDB 写入的数据，也没测试过帖子中的 txnkv 的场景，不建议在生产中使用。 请问针对primary key丢失的这种情况，tikv是能自我恢复吗？ 这种有 secondary key，但没有 primary key 的事务，理论上不能自动恢复。这里恢复可能是因为这个 key 不在 ticdc 监听的 region 中了，比如分裂到其他 region 了，也有可能是被手动清理掉了。

目前 TiCDC 仅支持同步 10 万表内的 TiDB 集群（包含最新的 6.5 版本）。可以在 changefeed 的配置中添加 [filter.rules] 过滤不必要的表，以减少同步表个数。 https://docs.pingcap.com/zh/tidb/stable/ticdc-changefeed-config

TiCDC 只保证最终一致，同步期间，上下游短暂数出现据不一致是有可能的。 在这个例子中，可能是“未同步”的 changefeed 同步慢了。

可以用 git diff 来看下修改，例如想从 6.1.0 升级到 6.5.0： git diff v6.1.0..v6.5.0 cdc/sink/sink.go