MyDumper 在 Azure MySQL 灵活服务器上出现段错误的分析与解决

问题背景

MyDumper 是一款高性能的 MySQL 逻辑备份工具，广泛应用于数据库备份场景。近期有用户报告在使用 MyDumper 备份 Azure Database for MySQL 灵活服务器（Azure 托管的 MySQL 服务）时遇到了段错误（Segmentation fault）问题。

问题现象

用户在执行 MyDumper 备份命令时，工具在尝试检测服务器版本阶段崩溃，产生以下错误：

** (mydumper:72): WARNING **: 17:40:22.016: Using --trx-tables options...
** (mydumper:72): WARNING **: 17:40:22.511: Not able to determine database version - ERROR 1049: Unknown database 'system'
Segmentation fault (core dumped)

通过分析核心转储文件，发现崩溃发生在 detect_server_version() 函数中。

技术分析

根本原因

经过深入分析，发现问题出在版本检测逻辑上。当 MyDumper 无法确定数据库类型时（SERVER_TYPE_UNKNOWN），它会尝试查询 system.build_options 表来获取版本信息。然而在 Azure MySQL 灵活服务器环境中：

1. 该表不存在，导致查询失败
2. 代码中释放了包含原始数据的 mr 结构体
3. 后续仍尝试访问已释放内存中的 ascii_version_comment 变量

版本检测流程

MyDumper 的版本检测逻辑大致如下：

1. 首先通过 SELECT @@version_comment, @@version 获取基础版本信息
2. 如果无法确定服务器类型，尝试查询 system.build_options 表
3. 对于 Azure MySQL，返回的版本信息格式为 "8.0.40-azure"
4. 在处理这些信息时，内存管理不当导致段错误

解决方案

项目维护者已修复此问题，主要改进包括：

1. 重构了 m_store_result* 系列函数的内存管理逻辑
2. 完善了版本检测失败时的处理流程
3. 确保在任何情况下都不会访问已释放的内存

用户建议

对于遇到类似问题的用户：

1. 避免在生产环境中使用 latest 标签的 Docker 镜像
2. 可以暂时回退到已知稳定的版本（如 v0.18-2-7）
3. 等待包含修复的正式版本发布后再升级

技术启示

这个案例展示了几个重要的技术要点：

1. 内存安全：在 C 语言开发中，必须谨慎管理内存生命周期
2. 错误处理：需要全面考虑各种可能的失败场景
3. 云服务兼容性：云厂商的 MySQL 变种可能与标准 MySQL 存在行为差异
4. 版本管理：生产环境应避免使用浮动标签（如 latest）

总结

MyDumper 团队快速响应并修复了这个 Azure MySQL 兼容性问题，体现了开源项目的活力。对于数据库工具开发者而言，这个案例也提醒我们需要特别关注不同云环境下的行为差异，确保工具的广泛兼容性。