MyDumper在MySQL 8从库备份导致主从延迟问题分析

问题背景

在使用MyDumper进行MySQL数据库备份时，从MySQL 5.7升级到8.0后出现了一个显著变化：在备份过程中从库会出现"seconds behind master"(SBM)延迟问题。这个问题在MySQL 5.7环境中并不存在，但在升级到MySQL 8.0.37后开始出现。

问题现象

用户在使用MyDumper v0.16.7-5对MySQL 8.0.37从库进行备份时，观察到以下现象：

1. 备份过程中从库出现明显的复制延迟
2. 使用--less-locking选项但问题依然存在
3. 通过SHOW PROCESSLIST可以看到有连接处于"Waiting for backup lock"状态
4. 从库状态显示"Waiting for dependent transaction to commit"

技术分析

MySQL 8.0的备份锁机制变化

MySQL 8.0引入了一个重要的新特性——备份锁(Backup Lock)。这是一种轻量级的DDL锁，旨在减少备份对数据库操作的影响。与传统的全局锁(FLUSH TABLES WITH READ LOCK)相比，备份锁允许在备份期间继续进行DML操作，但会阻塞DDL操作。

MyDumper的锁机制

MyDumper在备份过程中会获取多种锁以确保数据一致性：

1. DDL锁：通过LOCK INSTANCE FOR BACKUP实现
2. 全局锁：通过FLUSH TABLES WITH READ LOCK实现
3. 表级锁：对各个表进行锁定

在MySQL 8.0中，当MyDumper获取DDL锁时，从库的复制线程会因为需要等待这个锁而无法继续应用主库的变更，从而导致复制延迟。

问题根源

问题的核心在于MySQL 8.0的复制机制与备份锁的交互方式发生了变化。在MySQL 5.7中，备份操作不会阻塞复制线程，但在MySQL 8.0中：

1. 从库的SQL线程需要获取元数据锁来应用DDL变更
2. MyDumper的备份锁会阻塞这些元数据锁的获取
3. 导致复制线程等待，产生延迟

解决方案

针对这个问题，有以下几种解决方案：

1. 使用--skip-ddl-locks选项：这是最直接的解决方案，可以避免MyDumper获取DDL锁，从而防止阻塞复制线程。

2. 调整备份策略：

   • 在业务低峰期进行备份
   • 考虑使用物理备份工具如Percona XtraBackup
   • 从主库而不是从库进行备份

3. 优化MyDumper参数：

   • 减小--rows参数值，减少单个查询的数据量
   • 调整--chunk-filesize控制文件大小
   • 增加线程数分散负载

实施建议

对于生产环境，建议采用以下步骤：

1. 首先在测试环境验证--skip-ddl-locks的效果
2. 监控备份期间的资源使用情况和复制延迟
3. 根据业务需求调整备份窗口
4. 考虑使用更现代的备份工具如MySQL Shell的备份功能

总结

MySQL 8.0引入的备份锁机制改变了备份工具与复制线程的交互方式，这是导致MyDumper在从库备份时出现延迟的根本原因。通过使用--skip-ddl-locks选项可以有效地解决这个问题，但同时需要评估跳过DDL锁对备份一致性的潜在影响。

对于关键业务系统，建议全面评估备份策略，可能考虑结合多种备份方法来确保数据安全性和服务可用性的平衡。