TiDB 事务重试调研

lemonvita
发布于 2022-4-13 12:32
浏览
0收藏

 

本文将通过一个讲述小案例来展开不同事务模型下的SQL重试策略,且听我娓娓道来:

某日上班时间,研发同学跑过来对DBA吐槽:我看我们的日志,发现一条很简单的insert SQL在TiDB里面执行时间都10s+,慢的时候都1分钟,而且出现的频率比较高,帮我们查查什么问题?

OK,Let's GO!

开始排查和分析:
通过查看grafana的Overview相关的相关的监控页面,比如SQL Duration监控,确实发现SQL执行的“毛刺”,并且通过System info看不是偶发的系统资源抖动导致写入慢,其实业务也反馈这种“写入慢”出现的频率较高,其实排查问题先看监控是为了避免“写热点”或者硬件故障导致写入抖动。

通过监控排除一些故障点后,接下来需要通过排查tidb server的log,以及tidb slow log看是否有有价值的发现了。通过查看日志有重大的发现:

(1)tidb server 日志里面有大量的retry报警日志,发现大量的retrying、Write confilct以及retrycnt较高的报警日志。

[WARN] [session.go:664] [retrying] [conn=1165700] [schemaVersion=13873] [retryCnt=10]
[WARN] [session.go:713] [sql] [conn=1165697] [label=general] [error="[kv:9007]Write conflict, txnStartTS=420135027926630456, conflictStartTS=420135027979059203, conflictCommitTS=420135027979059208, key={tableID=14342, handle=10895814047} primary={tableID=14342, handle=10895814047} [try again later]"] [txn="Txn{state=invalid}"]
[WARN] [session.go:658] [retrying] [conn=1165702] [schemaVersion=13873] [retryCnt=0] [queryNum=0] [sql="INSERT INTO xxx"]

(2)tidb slow日志里面也有涉及上面慢SQL的记录,通过日志中SQL耗时情况查看,其中,Commit_backoff_time:表示commit重试时间,Backoff_types: [txnLock txnLock]表示重试类型是:集群中存在写写冲突,这些时间都很快,大家需要关注一个retry次数Txn_retry: 15次。

Time: 2021-08-06T13:40:50.216614662+08:00
Txn_start_ts: 426830302171889757
User: ad_stat@10.203.164.206
Conn_ID: 363
Query_time: 33.671954617
Parse_time: 0.0011528
Compile_time: 0.000609021
Prewrite_time: 0.489890509 Commit_backoff_time: 0.483 Backoff_types: [txnLock txnLock] Resolve_lock_time: 0.000715966 Write_keys: 50 Write_size: 9980 Prewrite_region: 6 Txn_retry: 15
DB: DB_XXXX
Is_internal: false
Digest: 3234fe71e25b4f3643f7c0c0528cc5544a8133c7628c59dbecb04537223ece8a
Num_cop_tasks: 0
Mem_max: 286500
Prepared: false
Plan_from_cache: false
Has_more_results: false
Succ: true
"INSERT INTO xxxxxxx”

https://docs.pingcap.com/zh/tidb/stable/identify-slow-queries#%E6%97%A5%E5%BF%97%E7%A4%BA%E4%BE%8B https://docs.pingcap.com/zh/tidb/stable/identify-slow-queries

写入慢的原因
首先先说上面出现问题的这个重试的环境和产生写入慢的原因 我们的环境:乐观+autocommit。原因:SQL有写冲突,再写冲突高的情况下导致了SQL的重试,从SQL的重试次数也会看出来,SQL重试导致的insert SQL执行时间过长。

写入重试场景分析
既然问题已经定位到是因为SQL重试导致的问题,那么TIDB什么场景下SQL会重试?以及SQL是如何重试的?重试次数有什么限制?OK,其实这个跟:tidb 的悲观/乐观事务模型,以及业务链接的隐式/显示事务有关系了。这里明确2个概念:(1)我如何知道我的TiDB集群是悲观 or 乐观模式,只需执行下面的SQL即可:

show variables like 'tidb_txn_mode’;

如果value=pessimistic那就是悲观模式, 如果value=‘’或者optimistic就是乐观模式。

(2)隐式 or 显示事务,取决于业务链接,隐式事务就是autocmmit事务。显示事务就是非autocommit事务或者通过begin/start translation;commit;命令显示开启的事务。

注意:这里强调一点要想实现跟MySQL一样的悲观事务模型需要tidbtxnmode= pessimistic,并且所有新创建 session 开启显示事务,具体关于悲观/乐观模式的详情可以去我上一篇公众号文章:写冲突场景下的悲观/乐观事务模型选择了解。

我这里用一个表格来说明重试场景:

TiDB 事务重试调研-鸿蒙开发者社区

(1)乐观+4.0.6版本前的隐式:默认10次乐观事务的重试

注意:具体由变量 tidb_disable_txn_auto_retry(是否禁用自动重试,默认1,不重试) 和 tidb_retry_limit(控制重试次数,默认10。当前面参数启用时才会生效) 控制。另外这2个参数仅适用于乐观事务,不适用于悲观事务。

(2)乐观+4.0.6之后版本的隐式:默认10次乐观事务的重试

(3)乐观+显示:tidbdisabletxnautoretry 的默认值为 on ,即不会重试非自动提交的事务,也就说这种情况遇到写冲突直接报错给client。

(4)悲观+4.0.6版本前的隐式:正如我上文强调的,虽然tidb是悲观模式,但是由于没有开显示事务,所以SQL遇到写冲突还是默认256次的乐观模式重试。

注意:悲观事务的重试次数由 maxretrycount(悲观事务中单个语句最大重试次数,重试次数超过该限制,语句执行将会报错,默认256)

(5)悲观+4.0.6之后版本的隐式:这里需要特别注意,虽然tidb是悲观模式,但是由于没有开显示事务,第一次是乐观提交,如果遇到写冲突后续TiDB帮着采用悲观提交,避免大量的乐观提交带来的写冲突。

(6)悲观+显示:不重试,跟MySQL悲观事务模式的行为一致。

大家明白tidb的SQL重试了么?

分类
标签
收藏
回复
举报
1条回复
按时间正序
/
按时间倒序
wx5eba0778dc082
wx5eba0778dc082

retry 这么多次后 是插入成功了还是失败了呢

 

insert 的sql 有问题吗? 没有问题的话 这个冲突怎么来的, 新插入的数据 和谁 冲突

 

这个重试 还是要业务层重试才对吧, 否则我业务是很多条件好满足才能执行的 时间冲突重试时 这些条件还满足吗 仅仅数据库重试这个语句有什么意思 会不会retry成功反而不应该

已于2022-7-22 21:32:14修改
回复
2022-7-22 21:23:40
回复