ShardingSphere-Proxy 前端协议问题排查方法及案例

ShardingSphere-Proxy 是 Apache ShardingSphere 的接入端之一，其定位为透明化的数据库代理。ShardingSphere-Proxy 实现了数据库协议，理论上可以被任何使用或兼容 MySQL / PostgreSQL / openGauss 协议的客户端访问。相比 ShardingSphere-JDBC，ShardingSphere-Proxy 的优势在于对异构语言的支持，以及为 DBA 提供数据库集群的可操作入口。

与 ShardingSphere 的 SQL 解析模块相似，ShardingSphere-Proxy 对数据库协议的支持度也是一个长期积累的过程，需要开发者不断去完善 ShardingSphere-Proxy 的数据库协议实现。

本篇将给大家介绍数据库协议开发过程中常用的工具，并以一次 ShardingSphere-Proxy MySQL 协议问题的排查过程作为本文工具使用的案例。

1

使用 Wireshark 分析网络协议

Wireshark 是一个常用的网络协议分析工具，其内置了对数百种协议的解析支持（包括本文相关的 MySQL / PostgreSQL 协议），能够读取多种不同类型的抓包格式。

Wireshark 的完整功能、安装等内容可以参考 Wireshark 官方文档^[1]。

1.1 使用 Wireshark 或 tcpdump 等工具抓包

1.1.1 使用 Wireshark 抓包

Wireshark 本身具备抓包能力，如果连接 ShardingSphere-Proxy 的环境可以运行 Wireshark，可以直接使用 Wireshark 抓包。

Wireshark 启动后，首先选择正确的网卡。

以本地运行 ShardingSphere-Proxy 为例，客户端通过 127.0.0.1 端口 3307 连接 ShardingSphere-Proxy，流量都经过 Loopback 网卡，因此选择 Loopback 作为抓包对象。

选择网卡后，Wireshark 即开始抓包。由于网卡中可能会有很多其他进程的流量，需要过滤出指定端口的流量：

tcp.port == 3307

1.1.2 使用 tcpdump 抓包

在 ShardingSphere-Proxy 部署在线上环境，或其他我们无法使用 Wireshark 抓包的情况下，可以考虑使用 tcpdump 或其他工具抓包。

对网卡 eth0 抓包，过滤 TCP 端口 3307，并将抓包结果写入到 /path/to/dump.cap。示例命令：

tcpdump -i eth0 -w /path/to/dump.cap tcp port 3307

tcpdump 的使用方式可以通过 man tcpdump 查看，本文不再赘述。tcpdump 的抓包结果文件可以通过 Wireshark 打开。

1.1.3 抓包注意事项

客户端连接 MySQL，可能会自动启用 SSL 加密，抓包结果无法直接解析出协议内容。使用 MySQL 命令行客户端可以指定参数禁用 SSL，命令如下：

mysql --ssl-mode=disable

使用 JDBC 可以增加参数，参数如下：

jdbc:mysql://127.0.0.1:3306/db?useSSL=false

1.2 使用 Wireshark 读取抓包内容

Wireshark 支持读取多种抓包文件格式，包括 tcpdump 的抓包格式。

Wireshark 默认会把 3306 端口解码 MySQL 协议、5432 端口解码为 PostgreSQL 协议。对于 ShardingSphere-Proxy 可能使用不同端口的情况，可以在 Decode As... 中为指定端口配置协议。

例如，ShardingSphere-Proxy MySQL 使用了 3307 端口，可以按照以下步骤把 3307 端口解码为 MySQL 协议：

当 Wirekshark 能够解析出 MySQL 协议后，我们可