MyDumper备份工具与MEMORY引擎表的死锁问题分析

问题背景

在使用MyDumper进行MySQL/MariaDB数据库备份时，当遇到使用MEMORY存储引擎的表时，可能会出现备份锁(backup lock)与表级锁(table level lock)之间的死锁情况。这种现象在备份过程中会导致MyDumper进程挂起，无法完成备份任务。

问题现象

具体表现为：

1. MyDumper进程显示"Waiting for backup lock"状态
2. 应用进程显示"Waiting for table level lock"状态
3. 当表引擎改为MyISAM或InnoDB时，问题不会出现
4. 终止任意一方进程后，另一方仍可能保持锁定状态

技术分析

MEMORY引擎特性

MEMORY存储引擎（原HEAP引擎）将表数据存储在内存中，具有以下特点：

• 数据访问速度极快
• 表结构在服务器重启后保留，但数据会丢失
• 默认使用表级锁定而非行级锁定
• 不支持事务

备份锁机制

MyDumper在执行备份时使用FLUSH TABLES WITH READ LOCK获取全局读锁，然后通过LOCK TABLES FOR BACKUP获取备份锁。这种机制在MariaDB中的特殊之处在于：

• 不会锁定不用于复制的临时表
• 但当需要写入二进制日志时，这些表会被阻塞

死锁成因

当MyDumper尝试备份MEMORY引擎表时：

1. MyDumper获取备份锁
2. 应用进程尝试更新MEMORY表
3. 由于MEMORY引擎的表级锁定特性，更新操作需要获取表锁
4. 同时备份锁阻止了表锁的获取
5. 形成互相等待的死锁局面

解决方案

方案一：修改表引擎

将MEMORY引擎表改为MyISAM或InnoDB引擎是最直接的解决方案：

ALTER TABLE server_updater ENGINE=InnoDB;

方案二：仅备份表结构

对于MEMORY这类易失性表，可以仅备份表结构而不备份数据：

1. 创建配置文件mydumper_extra.cnf：

[`test_db`.`server_updater`]
object_to_export=SCHEMA

2. 执行备份命令：

mydumper --defaults-extra-file=mydumper_extra.cnf [其他参数]

方案三：自定义补丁

对于高级用户，可以修改MyDumper源码实现选择性数据备份：

1. 添加表数据跳过列表功能
2. 在表结构导出阶段识别MEMORY引擎表
3. 自动跳过这些表的数据备份

最佳实践建议

1. 生产环境中慎用MEMORY引擎表
2. 对于必须使用MEMORY引擎的场景：
   • 考虑定期手动导出表结构
   • 在备份策略中明确处理这类特殊表
3. 监控备份过程中的锁等待情况
4. 测试环境充分验证备份恢复流程

总结

MyDumper与MEMORY引擎表的死锁问题源于存储引擎特性与备份锁机制的交互作用。通过理解底层原理，我们可以采用多种方式规避这一问题，确保备份任务的顺利完成。对于关键业务系统，建议优先考虑修改表引擎的方案，从根本上消除潜在风险。