commit_ts is too large, fallback to normal 2PC

🪐 TiDB 技术问题 部署&运维管理
1

【 TiDB 使用环境】生产
【 TiDB 版本】5,4,2
上游为tidb，ticdc同步
【遇到的问题】 频繁出现
[2022/07/29 18:40:19.936 +08:00] [WARN] [prewrite.rs:613] [“commit_ts is too large, fallback to normal 2PC”] [lock=“Lock { lock_type: Put, primary_key: 748000000000000AC95F698000000000000001038000000000000C32017370303030303233FF3739330000000000FA03800000000460A17A, start_ts: TimeStamp(434920802697347099), ttl: 23394, short_value: 30, for_update_ts: TimeStamp(0), txn_size: 1, min_commit_ts: TimeStamp(434920808031977475), use_async_commit: true, secondaries: [], rollback_ts: [] }”] [max_commit_ts=434920808567799835] [min_commit_ts=434920808752873488] [start_ts=434920802697347099] [key=748000000000000AFFC95F698000000000FF0000010380000000FF00001D7B01535048FF3030303437FF3830FF320000000000FA03FF80000000047CBE52FF0000000000000000F7]

2

猜测是 1PC或 aysnc commit 情况下，Prewrite时会根据写的key计算min_commit_ts，最后选择最大的作为commit_ts ,为保障start_ts -> commit_ts间 schema的一致性，tidb增加了一个max_commit_ts，max_commit_ts以Prewrite+2秒的时间计算，当min_commit_ts超过max_commit_ts后 就会报 commitTStoolarge错误，然后回退到2PC提交模式。 可能是prewrite时间较长导致。

3 个赞
3

这个库硬件配置比上游的低一些，执行比上游慢些。可以调整哪个参数，适当放长一些么？

4

看看系统负载，尤其下游的磁盘压力，raft相关线程CPU利用率、组件间的网络延迟，按下面导出下监控，导出时要等所有面板展开
https://metricstool.pingcap.com/#backup-with-dev-tools

5

该主题在最后一个回复创建后60天后自动关闭。不再允许新的回复。