分享好友

×
取消 复制
浅析MySQL协议——从一个bug谈起
2020-05-15 14:40:52

Bug描述

关于bug的描述,这里使用了项目的issue模板,大家在提bug的时候也请一定遵循这个模板。在本文中使用中文描述,但大家提issue的时候记得用英文,毕竟老外也会来看的。

Which version of Sharding-Sphere do you using?

3.0.0.M2-SNAPSHOT

Which project do you using? Sharding-JDBC or Sharding-Proxy?

Sharding-Proxy

Expected behavior

持续正常的INSERT数据。

Actual behavior

循环插入200万数据,当插入到100万左右的时候,客户端无响应。

Reason analyze

客户端无响应可能是Proxy阻塞引起的,也可能是Proxy导致客户端阻塞引起的。

Steps to reproduce the behavior

持续插入数据到100万条以上即可复现。

Bug初步定位

经过初步分析,Proxy日志正常,MySQL里也能查到用户插入的最后一条数据。那么,问题应该就出在最后一条数据插入成功之后。可能有两种情况:1. 插入数据成功后,MySQL返回的消息被Proxy错误解码,导致Proxy异常;2. Proxy返回给客户端的消息编码错误,导致客户端异常。

第一种情况,如果Proxy解码错误,Netty会抛异常,TCP连接断开,Proxy会把异常打印到日志,所以这种情况可能性不大。第二种情况可能性较大,需要分析Proxy和客户端之间的消息交互,进一步定位。

MySQL协议

准确的说应该是MySQL Client/Server协议,另一个叫X Protocol的暂不涉及。任何MySQL客户端(CLI、GUI、MySQL驱动)与MySQL服务器通信,都需要使用这个协议。这个协议包含一系列的命令消息(COM)和响应消息(Response)、编解码方式和交互流程。


上图展示了绝大多数协议消息的交互过程:对于DQL,服务器会返回FIELD_COUNT(列数)、FIELD(列的描述信息,如类型等)、ROW(每一行数据的值)、EOF(结束标志);而对于DML,只需要返回OK或者ERR,通知客户端命令执行成功或失败。

经过之前的分析,我们可以把范围缩小到OK_Packet这条响应消息上,这条消息由服务器发送给客户端,表示一条命令的成功执行。也就是说,在插入数据成功后,MySQL服务器会发送OK_Packet给Proxy,后者又会把这条消息发送给客户端。消息格式如下:

这个表格看起来有点抽象,我们可以先用Wireshark抓个真实包看看,解析出来会直观一些:

做协议开发永远离不开Wireshark,后面拓海会手把手教你使用Wireshark进行网络抓包。真实的数据看起来就简单明了一些了,有包长度、包序号、影响行数、最后插入id、服务器状态等信息。我们找一个字段,来说明其编解码方式。例如last_insert_id,它的类型是int<lenenc>,值为1083。

MySQL协议里存储数据的方式是小端字节序,这是什么意思呢?比如一个值0x1234,采用大端字节序的存储方式就是0x1234,而小端方式则是0x3412。MySQL采用这样的字节序很不友好,对于一个通信协议,应该使用网络字节序传输数据,而不是机器字节序。

回到协议,int<lenenc>是变长编码的整数类型,不同范围的数值使用不同的长度来编码:

由上可知,1083这个值应该是0xfc 加上2个字节来表示:

1083 = 0x043b,小端字节序就是0x3b04。有了这些基础,我们就可以通过抓包来分析产生bug的根本原因了。

Bug最终定位

以下就是当时抓到的包,看起来非常的“正常”,插入一条数据,返回一条成功的响应,Wireshark也没有解析出错。看现象就是客户端停止了插入数据。

经过多次试验,最后一条INSERT总是卡在t_order_item这个表上,它与t_order表有什么本质区别呢?了解Sharding-Sphere-Example的同学对这两个表应该很熟悉,t_order使用的是雪花算法生成的分布式主键,值很大,而t_order_item使用的是MySQL自增主键。为什么主键值小的表会卡住?

又经过一系列调查,发现t_order_item表也不是每次都卡住,这个表有两个分片,在其中一个分片上永远没问题,而另一个分片上只要插入数据就会卡。这两个表又有什么区别呢?其实,由于分片的不均匀,一个表的数据量多,另一个数据量少,除此之外没什么不同。数据量多的表大概6万多条数据。

在拓海百思不得其解的时候,亮神和赵帅看出了些端倪:

最后一条OK_Packet的Last INSERT ID值太大了,一个表不可能有这么多数据。通过观察发现,表的数据量已经大于65535,应该使用3个字节存储

然而程序里却使用了四个字节。四个字节的编码在协议里是不存在的,这必然导致客户端jdbc解析出错。至于为什么wireshark没有解析出错,那一定是因为它的解析逻辑错了。

使用Wireshark分析MySQL协议

Wireshark可以理解为是一个带图形界面的tcpdump,同时集成了非常多的协议解析插件,可以帮助我们方便的抓取和分析MySQL协议。需要注意的是,Wireshark只能抓网络协议包,但MySQL协议还有其他通信方式,如Shared memory,Named pipes,这些是抓不到的,最好不要开这些参数。

Linux命令行环境下:可以先用tcpdump抓包,然后将包发送到本地,使用Wireshark解析。命令如下:

tcpdump -i any port 3307 -w test.pcap

any: 表示所有网络接口。

port: tcp端口,Proxy的默认端口是3307,如果你关心MySQL的包,就改为3306。

pcap: 一种通用的数据流格式,Wireshark可以直接打开。

用Wireshark打开test.pcap,你会发现除了MySQL协议,还显示很多TCP协议的ACK消息:

在过滤器中输入mysql,进行过滤即可:

Windows环境下:直接使用Wireshark抓包,一边抓包一边解析。本地的测试环境往往会同时运行客户端、Proxy和MySQL服务器,它们的通信在同一台机器上是不走网卡的,然而windows系统又没有提供本地回环网络的接口,所以这种情况下是什么也抓不到的。

为了解决这个问题,我们需要把Wireshark在Windows系统上默认的抓包工具WinPcap替换为Npcap,在这里下载:https://nmap.org/npcap/#download

安装前先在Wireshark的安装目录下卸载WinPcap。安装时勾选如下选项:


安装完成再次启动Wireshark时,就会看到在网络接口列表中,多了一项Npcap Loopback adapter,这个就是来抓本地回环包的网络接口了:

小结

Sharding-Sphere自2016开源以来,不断精进、不断发展,被越来越多的企业和个人认可:在Github上收获5000+的star,1900+forks,60+的各大公司企业使用它,为Sharding-Sphere提供了重要的成功案例。此外,越来越多的企业伙伴和个人也加入到Sharding-Sphere的开源项目中,为它的成长和发展贡献了巨大力量。

我们从未停息过脚步,聆听社区伙伴的需求和建议,不断开发新的强大功能,不断使其健壮可靠!开源不易, 我们却愿向着最终的目标,步履不停!那么,正在阅读的你,是否可以助我们一臂之力呢?分享、转发、使用、交流,以及加入我们,都是对我们最大的鼓励!

Sharding-Sphere是一套开源的分布式数据库中间件解决方案组成的生态圈,它由Sharding-JDBC、Sharding-Proxy和Sharding-Sidecar这3款相互独立的产品组成。他们均提供标准化的数据分片、读写分离、柔性事务和数据治理功能,适用于如Java同构、异构语言、容器、云原生等各种多样化的应用场景。
亦步亦趋,开源不易,您对我们最大支持,就是在github上留下一个star。

分享好友

分享这个小栈给你的朋友们,一起进步吧。

Apache ShardingSphere
创建时间:2020-05-14 09:44:48
Apache ShardingSphere 是一套开源的分布式数据库中间件解决方案组成的生态圈,它由Sharding-JDBC、Sharding-Proxy和Sharding-Sidecar(规划中)这3款相互独立,却又能够混合部署配合使用的产品组成。它们均提供标准化的数据分片、分布式事务和数据库治理功能,可适用于如Java同构、异构语言、云原生等各种多样化的应用场景。 ShardingSphere定位为关系型数据库中间件,旨在充分合理地在分布式的场景下利用关系型数据库的计算和存储能力,而并非实现一个全新的关系型数据库。它通过关注不变,进而抓住事物本质。关系型数据库当今依然占有巨大市场,是各个公司核心业务的基石,未来也难于撼动,我们目前阶段更加关注在原有基础上的增量,而非颠覆。 ShardingSphere已经在2020年4月16日成为Apache顶级项目(Apache官方发布从4.0.0版本开始)。
展开
订阅须知

• 所有用户可根据关注领域订阅专区或所有专区

• 付费订阅:虚拟交易,一经交易不退款;若特殊情况,可3日内客服咨询

• 专区发布评论属默认订阅所评论专区(除付费小栈外)

技术专家

查看更多
  • ☀️
    专家
戳我,来吐槽~