MyDumper 并发备份与DDL操作死锁问题分析

问题背景

在使用MyDumper工具对MySQL 8.0.25数据库进行备份时，当同时有DDL操作在同一schema上执行时，可能会出现MyDumper进程、DDL语句以及DML语句全部卡住的情况。这个问题在MyDumper 0.16.1-2和0.16.6-2版本中均存在。

问题现象

当MyDumper执行备份任务时，如果同时执行类似CREATE DATABASE IF NOT EXISTS这样的DDL操作，系统可能会出现以下情况：

1. MyDumper进程卡住
2. DDL语句执行被阻塞
3. 相关的DML语句也被阻塞

通过检查MySQL的performance_schema.metadata_locks和processlist，可以发现存在锁等待的情况。

技术分析

锁等待的根本原因

问题源于MyDumper在执行SHOW TABLE STATUS命令时使用了事务。具体表现为：

1. MyDumper线程启动一个事务并执行SHOW TABLE STATUS，这会获取SCHEMA IX锁(意向排他锁)
2. 同时执行的DDL操作需要获取SCHEMA X锁(排他锁)
3. IX锁和X锁不兼容，导致DDL操作等待
4. MyDumper的其他线程执行SELECT或EXPLAIN语句时，如果MySQL表缓存中没有相关表，也会请求SCHEMA IX锁
5. 这些IX锁请求被持有IX锁的线程阻塞，而持有IX锁的线程又在等待其他线程完成工作
6. 最终形成死锁状态，所有相关操作都被阻塞

复现步骤

1. 准备一个包含约20个表并有数据的测试数据库(如bc_sbtest)
2. 启动MyDumper备份命令
3. 快速执行CREATE DATABASE IF NOT EXISTS bc_sbtest语句
4. 观察系统状态，多次尝试可稳定复现

解决方案

临时解决方案

1. 使用--trx-consistency-only参数替代--no-locks：

   • 该参数允许MyDumper使用FTWRL(全局读锁)
   • 对于纯InnoDB表环境是安全的
   • 会在查询表信息前释放锁，减少锁定时间

2. 避免在备份期间执行DDL操作

长期改进建议

1. 修改MyDumper的工作流程：

   • 将所有dump任务预先创建好
   • 然后让工作线程执行数据导出
   • 避免在事务中执行SHOW TABLE STATUS

2. 增加专门的DDL锁选项：

   • 允许单独控制FTWRL和LOCK INSTANCE FOR BACKUP
   • 提供更细粒度的锁控制

技术建议

对于包含大量表的schema备份，建议：

1. 优先使用--trx-consistency-only参数
2. 合理安排备份时间，避开业务高峰期
3. 对于超大规模数据库，考虑分批次备份
4. 监控metadata_locks，及时发现锁等待问题

这个问题揭示了在复杂数据库环境中备份工具与DDL操作的交互问题，开发团队正在评估更彻底的解决方案，以从根本上避免此类死锁情况的发生。