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

#1

【 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赞
#2

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

2赞
#3

有的，我发出来

#4

v5.3.0

image
image.png2828×990 699 KB

v4.0.14

image
image.png1546×1084 410 KB

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

#5

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

#6

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

#7

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

#8

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;

#9

select @@net_read_timeout;

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

#10

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

#11

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

#12

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

#14

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

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

#15

[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;

#16

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协议相关部分不知道有没有变动。

#17

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

#18

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

#19

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

#20

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

#21

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