txnKV 暂不支持 CDC，从 Raft 日志层面能否自定义捕获 txnKV 增量数据，难点在哪？
Region 分散时序乱、预写回滚日志多、日志定期裁剪丢历史、KV 需依赖 Schema 解析 SQL、Leader 切换位点难维护。
1 个赞
可以先用 TiDB Dashboard 的 SQL 分析看下慢查询，定位问题的大概范围。具体报错信息贴出来比较好帮忙分析。
1 个赞
Raft 日志层面理论可自定义捕获 txnKV 增量，但工程落地难度极高，无法复刻 TiCDC 事务一致性能力，也是官方 TiCDC 暂不原生适配 txnKV 的核心原因落地最优方案：新增 Raft Learner 节点旁路消费 Raft Log，禁止在业务 TiKV 上插钩子解析日志。
1 个赞
Raft 日志仅记录原始 KV 操作（如 Put/Delete），不保留事务边界（Prewrite/Commit/Rollback）或逻辑变更类型（INSERT/UPDATE/DELETE），需在 Apply 阶段结合 Lock/Data/Write CF 解析事务结构，这要求深度耦合存储引擎内部格式。
试试 优先切 APIv2 启用原生 TiCDC，放弃自研 Raft 解析。
1 个赞
能用 TiCDC 绝不自研 Raft 抓取 txnKV。
从数据库设计角度，这类问题通常可以归结为数据模型和访问模式的匹配度问题。具体需要看你的 schema 和查询模式才能给出更针对性的建议。
你可以基于 TiCDC 的架构开发自定义插件，以实现更细粒度的数据捕获和处理逻辑。这通常涉及到对 TiCDC 的源码进行修改，并重新编译部署。
Raft 日志只持久化底层 Put、Delete 这类原生 KV 指令，不存储事务的 Prewrite、Commit 事务标记，也不记录上层 SQL 的增删改逻辑；等到 Apply 落地阶段，依靠解析 Lock、Data、Write 三大列簇还原完整事务，因此和底层存储引擎数据结构深度绑定。
理论上可通过 Raft 日志捕获 txnKV 增量数据，但落地难度大。难点包括日志缺少事务标记、需要解析底层列簇还原事务，Region 时序混乱、日志会被裁剪、Leader 切换易造成位点异常。建议优先使用原生 TiCDC，如需自研可借助 Raft Learner 节点旁路消费日志。
此话题已在最后回复的 7 天后被自动关闭。不再允许新回复。