ticdc的min resolved ts有较长的滞后

🪐 TiDB 技术问题
, ,
1

【 TiDB 使用环境】生产环境，4个tikv节点

【 TiDB 版本】tikv 6.1

【复现路径】
监听cdc， 根据监听到的cdc内容，再使用txnkv往tikv写入
在上述操作进行的同时进行着range delete操作

【遇到的问题：问题现象及影响】
txn往tikv写入时client端报错：
[ERROR] [commit.go:182] [“2PC failed commit key after primary key committed”] [error=“Error(Txn(Error(Mvcc(Error(TxnLockNotFound { start_ts: TimeStamp(439331133747363841), commit_ts: TimeStamp(439331134009508037), key: [0, 0, 0, 0, 0, 0, 0, 11, 0, 0, 88, 195, 0, 0, 1, 132, 128, 217, 196, 16, 151, 5, 146, 83, 118, 61, 0, 0] })))))”] [errorVerbose=“Error(Txn(Error(Mvcc(Error(TxnLockNotFound { start_ts: TimeStamp(439331133747363841), commit_ts: TimeStamp(439331134009508037), key: [0, 0, 0, 0, 0, 0, 0, 11, 0, 0, 88, 195, 0, 0, 1, 132, 128, 217, 196, 16, 151, 5, 146, 83, 118, 61, 0, 0] })))))\ngithub.com/tikv/client-go/v2/error.ExtractKeyErr\n\t/go/pkg/mod/github.com/tikv/client-go/v2@v2.0.1-0.20220531092439-efebaeb9fe53/error/error.go:259\ngithub.com/tikv/client-go/v2/txnkv/transaction.actionCommit.handleSingleBatch\n\t/go/pkg/mod/github.com/tikv/client-go/v2@v2.0.1-0.20220531092439-efebaeb9fe53/txnkv/transaction/commit.go:171\ngithub.com/tikv/client-go/v2/txnkv/transaction.(*batchExecutor).startWorker.func1\n\t/go/pkg/mod/github.com/tikv/client-go/v2@v2.0.1-0.20220531092439-efebaeb9fe53/txnkv/transaction/2pc.go:1993\nruntime.goexit\n\t/usr/local/go/src/runtime/asm_amd64.s:1571”] [txnStartTS=439331133747363841] [commitTS=439331134009508037] [keys=“[000000000000000b00004e1900000186345e80b0fee6f0a456410000,000000000000000b000058c30000018480d9c41097059253763d0000,000000000000000b00005a1f000001863424e69897059253762c0000]”] [stack=“github.com/tikv/client-go/v2/txnkv/transaction.actionCommit.handleSingleBatch\n\t/go/pkg/mod/github.com/tikv/client-go/v2@v2.0.1-0.20220531092439-efebaeb9fe53/txnkv/transaction/commit.go:182\ngithub.com/tikv/client-go/v2/txnkv/transaction.(*batchExecutor).startWorker.func1\n\t/go/pkg/mod/github.com/tikv/client-go/v2@v2.0.1-0.20220531092439-efebaeb9fe53/txnkv/transaction/2pc.go:1993”]

然后从这个时候开始，服务就开始监听不到cdc的信息，打开监控发现某一台机器的min resolved ts一直滞后且不变

看golang tikv client代码，貌似报 2PC failed commit key after primary key committed 这个错可能是个很严重的bug?

【资源配置】
【附件：截图/日志/监控】

ticdc监控
1676119742091_5206E905-9792-4254-9073-F0B75D7558AF

图中绿色就是一直滞后的，到后面自己恢复了

tikv相关日志

[INFO] [commit.rs:67] [“txn conflict (lock not found)”] [commit_ts=439331134009508037] [start_ts=439331133747363841] [key=000000000000000BFF000058C300000184FF80D9C41097059253FF763D000000000000FB]

[WARN] [errors.rs:339] [“txn conflicts”] [err=“Error(Txn(Error(Mvcc(Error(TxnLockNotFound { start_ts: TimeStamp(439331133747363841), commit_ts: TimeStamp(439331134009508037), key: [0, 0, 0, 0, 0, 0, 0, 11, 0, 0, 88, 195, 0, 0, 1, 132, 128, 217, 196, 16, 151, 5, 146, 83, 118, 61, 0, 0] })))))”]

2

2PC failed commit key after primary key committed

是没找到提交的主键，基本上就是锁丢了…

为什么会出现提交超时的情况呢？ 需要你自己检查下环境和配置了

这个和cdc 没多大关系

3

您好，请教一下锁丢了可能是什么原因导致的

另外您说的提交超时是指commit阶段一直不结束吗，commit在tikv里面超时不会自动失败掉吗

4

理论上，commit 会有两种结果，successs 和 rollback

如果是 rollback，和锁的释放，没有必然关系，参考文档：
https://docs.pingcap.com/zh/tidb/stable/garbage-collection-overview#resolve-locks清理锁

你提的问题呢，因为环境信息太少了，没办法判断
以我的经验来看，一般不会出现这样的情况…

5

应该是事务的primary key提交了。但是secondary key还没有提交，这个时候primary key被delete range操作给删掉了，然后导致secondary key一直没法提交。

还有一个问题想请教一下，看监控上显示，过了一天之后，resolve ts自我恢复了。请问针对primary key丢失的这种情况，tikv是能自我恢复吗？

6

TiCDC 不支持同步非 TiDB 写入的数据，也没测试过帖子中的 txnkv 的场景，不建议在生产中使用。

请问针对primary key丢失的这种情况，tikv是能自我恢复吗？

这种有 secondary key，但没有 primary key 的事务，理论上不能自动恢复。这里恢复可能是因为这个 key 不在 ticdc 监听的 region 中了，比如分裂到其他 region 了，也有可能是被手动清理掉了。

7

好的，谢谢