使用tidb v5.3.0 作为proxysql v2.3.2 的后端,客户端重连会复用session变量, 在tidb v4.0.14下是正常的

【 TiDB 使用环境】生产环境 or 测试环境 or POC
生产
【 TiDB 版本】
v5.3.0
【遇到的问题】

使用tidb v5.3.0 作为proxysql v2.3.2 的后端,客户端重连会复用上一个连接的session变量。但是把后端切换为 tidb v4.0.14下是正常的。

【复现路径】做过哪些操作出现的问题

  1. 保证tidb v5.3 作为proxysql v2.3.2的后端

  2. 连接proxysql 并且执行 ‘select @@net_read_timeout’, 结果是30

  3. 接着继续执行 ’ SET tidb_mem_quota_query=35433480192,interactive_timeout=28800,wait_timeout=2147483,net_write_timeout=86400,net_read_timeout=8640; ’

  4. 断开连接并且重连proxysql 执行 ‘select @@net_read_timeout’, 结果是’86400’, 期望结果是 ‘30’.

  5. 把proxysql 后端切换为 tidb v4.0.14,重复上面测试步骤,结果是正确的,并且不会复现。

  6. tidb v5.3 这个问题是必现的。

【问题现象及影响】

  1. 导致tidb 无法和proxysql 配合,影响线上架构

【附件】

1.下面是在proxysql项目的issue, 作者怀疑是tidb 5.3的bug:
https://github.com/sysown/proxysql/issues/3832

1赞

可以开启general log抓取下两次的详细信息看看吗?多谢

2赞

有的,我发出来

v5.3.0

v4.0.14

我这个日志是把 select @@ net_read_timeout. 换成了 select @@tidb_snapshot, 效果是一样的。
从general log 上来看,两个版本没啥大的区别, 就是tidb v5.3 中间多了不少 use snapshot schema

我看github 上贴了 proxysql 的报错日志,这个报错日志的时间点是在新 session 之后还是之前的?

proxysql 这个报错日志在v4.0.14 和 v5.3.0 都有, set 语句发过去就会报错,但并不影响实际执行

5.3好像没有包含SET?另外麻烦发一下两个文本信息吧,多谢。

select @@tidb_snapshot;

SET tidb_mem_quota_query=35433480192,tidb_snapshot=432222672485089283,interactive_timeout=28800,wait_timeout=2147483,net_write_timeout=86400,net_read_timeout=8640;

select @@net_read_timeout;

SET tidb_mem_quota_query=35433480192,interactive_timeout=28800,wait_timeout=2147483,net_write_timeout=86400,net_read_timeout=8640;

截图是我截漏了, 主要就是上面的sql

是不是可以这样:在 tidb 主机,tcpdump 抓包;然后刚刚的问题复现一遍;然后把抓的包款看下
如果有多 tidb 实例的话,是不是可以先 弄一个?这样好抓

我测试的时候设置了proxysql 和tidb 是一对一。 好的我抓下包,一会儿发上来

我回邮件了,不知道能否看到
想希望再麻烦你,抓包直接保存到文件, 大概命令如下(即之前的命令,加个 “-w xxx.cap” 就可以了)
Tcpdump port xxx -w v5.3.cap

主要这样就可以看到具体报文的内容,包括 set 之类

[quote=“upstream889, post:13, topic:662908”]

tidb v5.3

  • proxysql ip : 10.9.104.227
  • tidb ip: 10.9.179.7

v5.3.0.cap (8.4 KB)

tidb v4.0.14

  • proxysql Ip: 10.9.154.38
  • tidb ip: 10.9.181.248

v4.0.14.cap (10.2 KB)

sql 执行顺序

  • select @@net_read_timeout;

  • SET tidb_mem_quota_query=35433480192,interactive_timeout=28800,wait_timeout=2147483,net_write_timeout=86400,net_read_timeout=8640;

  • select @@net_read_timeout;

5.7.25-TiDB-v4.0.14
5.7.25-TiDB-v5.3.0-20220107

https://bugs.mysql.com/bug.php?id=102266

这里不禁好奇的问下,tidb大版本升了,tidb server源码里的mysql协议相关部分不知道有没有变动。

再补充问一句啊:在重新登陆之后,就 net_read_timeout 有问题,还是其它几个都这样(比如 tidb_mem_quota_query, net_write_timeout , wait_timeout 等等)

我测试下来,之前设置过的都有问题, 尤其是tidb_snapshot 这个影响最大,新连接没法执行写操作

changeuser 的时候,可能 session 的变量没及时调整,这个要去扒代码了,可能要一会儿
image

对的,是这样的流程。:pray:

看你们很紧急,所以是不是可以考虑先看看是不是可以不要重用连接——先规避这个问题
当然,我们这边继续看这个问题