tikv 节点重启后,集群响应时间飙升问题

【 TiDB 使用环境】生产环境
【 TiDB 版本】v6.1.4
【复现路径】tikv 某一个节点重启后,另一个节点开始输出 prepare_write_err 异常。
【遇到的问题:问题现象及影响】集群整体时延上升
【资源配置】8台tikv 机器 24 实例
【附件:截图/日志/监控】




tidb 节点有报错:
[2023/11/09 11:15:08.205 +08:00] [WARN] [session.go:1966] [“run statement failed”] [schemaVersion=233964] [error=“previous statement: update mysql.table_cache_meta set lock_type = ‘READ’, lease = 445513650692423680 where tid = 203252: [kv:9007]Write conflict, txnStartTS=445513651491963030, conflictStartTS=445513651491963037, conflictCommitTS=0, key={tableID=57, handle=203252} primary=[]byte(nil) [try again later]”] [session=“{\n "currDBName": "",\n "id": 0,\n "status": 2,\n "strictMode": true,\n "user": null\n}”]
[2023/11/09 11:15:08.205 +08:00] [WARN] [cache.go:205] [“lock cached table for read”] [error=“previous statement: update mysql.table_cache_meta set lock_type = ‘READ’, lease = 445513650692423680 where tid = 203252: [kv:9007]Write conflict, txnStartTS=445513651491963030, conflictStartTS=445513651491963037, conflictCommitTS=0, key={tableID=57, handle=203252} primary=[]byte(nil) [try again later]”]

重启tikv节点的日志发一下,有问题的tikv节点不行先踢掉,先止损

有小表设置成cache表了吗?

1 个赞

确实是,把小表挪出来之后就恢复了

tikv是不是在做数据同步啊

收集一下日志,产研老师看看

应该是由于重启导致了事务异常失败
之后数据中残留了大量的事务相关的锁
在重启之后的清锁过程,造成的事务延迟上升

tikv重启导致事务失败这说不过去吧,而且他把表取消cache后就好了

那就得查查冲突的来源是不是都是在 cached table 上面

他提供的tidb日志里 显示的这个元数据表冲突