故障分析 | MySQL : slave_compressed_protocol 导致 crash

作者：胡呈清

作为爱可生 DBA 团队成员，专注于故障分析和性能优化，个人博客：https://www.php.cn/link/644d47ad4e86f0e50d1904691958f743。

本文内容为原创投稿，由爱可生开源社区出品。未经授权，严禁随意使用。转载请联系小编并注明来源。

现象
MySQL 版本：8.0.18

create.sql：zabbix 初始化脚本，包含建表和插入数据语句，文件大小超过 10M。

一位新客户部署了我们公司的数据库管理平台，并接管了一主两从的 MySQL 实例。其中，一主一从位于无锡机房，采用半同步复制，另一从库位于北京机房，使用异步复制。在主库上执行 source create.sql 命令时，会导致数据库崩溃。但在接管到平台之前，执行相同操作并不会引发崩溃。

排查过程

1. 在测试环境复现问题
   为了方便排查，我们在可控的测试环境中进行了复现：

   • 使用与客户相同的 my.cnf 配置文件
   • 相同版本的 MySQL
   • 相同的复制架构
   • 执行相同的 create.sql 脚本

   确实可以稳定复现崩溃问题，错误日志如下：

2. 排除管理平台的影响
   由于崩溃问题只在接管到管理平台后出现，而管理平台对数据库的主要操作来自于高可用组件：

   • 延迟检测（每 500ms 写入一个时间戳）
   • 状态查询（读操作）

   因此，我们停用了高可用组件和延迟检测进行测试，结果如下：

初步结论：关闭延迟检测后，不会发生崩溃。

3. 延迟检测如何影响崩溃
   在测试过程中，我们发现了一个与崩溃相关的现象：

   • 启用延迟检测时，会发生崩溃，但 SQL 执行效率较高（毫秒级）。
   • 停用高可用检测时，不会崩溃，但每个 SQL 执行时间超过 1 秒。

   这看起来像是组提交机制导致的问题，但实际上并没有配置组提交参数：

   <code>mysql> show global variables like '%group_commit%';
   +-----------------------------------------+-------+
   | Variable_name                           | Value |
   +-----------------------------------------+-------+
   | binlog_group_commit_sync_delay          | 0     |
   | binlog_group_commit_sync_no_delay_count | 0     |
   +-----------------------------------------+-------+
   2 rows in set (0.01 sec)</code>

   关闭半同步复制后，此现象也会消失。我们猜测是半同步复制和组提交结合在一起引发的问题。

4. longblob 大对象的影响
   在前面的测试中，每次复现崩溃时，解析 binlog 查看最后一个事务时发现一个共同点：都是向同一张表插入数据：

   <code>### INSERT INTO `zabbix`.`images`
   ### SET
   ###   @1=108 /* LONGINT meta=0 nullable=0 is_null=0 */
   ###   @2=1 /* INT meta=0 nullable=0 is_null=0 */
   ###   @3='Rackmountable_3U_server_3D_(64)' /* VARSTRING(256) meta=256 nullable=0 is_null=0 */
   ###   @4=</code>

   查看表结构，发现表中有 longblob 大对象，插入的是图片数据，使用二进制格式存储：

   

   Woy AI

   通过 Woy.ai AI 导航站发现 2024 年顶尖的 AI 工具！

   下载

   <code>CREATE TABLE `images` (
     `imageid` bigint(20) unsigned NOT NULL,
     `imagetype` int(11) NOT NULL DEFAULT '0',
     `name` varchar(64) NOT NULL DEFAULT '0',
     `image` longblob NOT NULL,
     PRIMARY KEY (`imageid`),
     UNIQUE KEY `images_1` (`name`)
   ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci;</code>

   从 create.sql 中截取 images 表的所有 INSERT 语句，仅执行这些语句也能够复现崩溃问题：

   <code>sed -n '2031,2217p' create.sql > insert.sql</code>

   因此，崩溃的第二个条件是：插入 longblob 大对象。

5. slave_compressed_protocol 的影响
   前面的分析已经找到两个触发崩溃的条件：

   • 插入数据时存在 longblob 大对象
   • 半同步复制，并且在插入 longblob 大对象时伴随有其他外部写入流量

   但实际上，使用数据库管理平台标准安装的相同版本的 MySQL 环境，并不能复现崩溃问题。区别在于 my.cnf 配置文件不同，所以一定还有某个参数作为触发条件。

   经过不断的测试，每次修改一批参数（注意前面已经定位到跟半同步复制有关，所以一定要同时修改主、从库的参数），不断缩小范围，最终定位到是从库设置 slave_compressed_protocol=on 的影响。

   从库 slave_compressed_protocol=ON 时，还会导致从库的 slave io thread 不断断开与主库的连接，并不断重连，从库错误日志报错如下：

   主库错误日志报如下错：

   相应的，由于从库 slave io 线程不断重连，可以观察到主库的 binlog dump 线程会不断重启，有时还可以观察到两个：

   <code>show processlist;
   select sleep (1);
   show processlist;
   ...
   | 2131 | admin | 172.16.21.3:37926 | NULL | Binlog Dump GTID | 3 | Waiting to finalize termination | NULL |
   | 2132 | admin | 172.16.21.3:37932 | NULL | Binlog Dump GTID | 1 | Sending binlog event to slave | NULL |
   ...
   +-----------+
   | sleep (1) |
   +-----------+
   | 0         |
   +-----------+
   ...
   | 2132 | admin | 172.16.21.3:37932 | NULL | Binlog Dump GTID | 2 | Sending binlog event to slave | NULL |
   ...</code>

   与之相关的 bug：

   • https://www.php.cn/link/e17d574a9ac6743fda8847722a2ce8c3
   • https://www.php.cn/link/94fb5e0d0f503714002dd7ba30e89195

结论
此次崩溃的触发条件有三个：

• 插入 longblob 大对象；
• 半同步复制，并且在插入 longblob 大对象时伴随有其他外部写入流量；
• slave_compressed_protocol=on。

为什么在接管到平台之前没有发生过崩溃？

因为该库尚未上线，在执行 create.sql 时没有其他写入流量（等同于关闭延迟检测的效果）。

解决方案
后续，我们的研发团队向官方提交了一个 bug：https://www.php.cn/link/ed18370ab753647f8aa890dab473e6b7。

由于一些安全问题（具体细节无法透露），此 bug 被官方设置为私密 bug，截图如下。不过截至今天（2021.12.28），官方仍未修复：