【 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]
猜测是 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 个赞
这个库硬件配置比上游的低一些,执行比上游慢些。可以调整哪个参数,适当放长一些么?
看看系统负载,尤其下游的磁盘压力,raft相关线程CPU利用率、组件间的网络延迟,按下面导出下监控,导出时要等所有面板展开
https://metricstool.pingcap.com/#backup-with-dev-tools
该主题在最后一个回复创建后60天后自动关闭。不再允许新的回复。