MyDumper/myloader 数据库备份恢复工具中的表过滤功能问题分析

问题背景

在使用MyDumper/myloader这套MySQL数据库备份恢复工具时，用户报告了一个关键问题：当使用myloader进行数据恢复时，如果指定了-s参数来过滤特定表，恢复过程会意外停止，无法完成操作。这个问题在简单测试环境下也能稳定复现，表明这是一个普遍存在的功能缺陷。

问题现象

用户在执行以下典型操作流程时遇到了问题：

1. 首先使用mydumper创建数据库备份：

mydumper --compress --use-savepoints --less-locking --triggers --events -v 3 --dirty --threads 4 -o /backup/20240312

2. 然后尝试使用myloader恢复特定数据库中的表：

myloader -s testdb -d /backup/20240312 -B restoredb --innodb-optimize-keys

恢复过程会卡住，无法完成，必须使用kill -9强制终止进程。通过检查发现，虽然数据库和表结构被创建了，但表数据没有被正确恢复。

技术分析

经过开发团队深入调查，发现问题的根源在于表过滤功能的实现逻辑存在缺陷。具体表现为：

1. 当使用-s参数指定要恢复的表时，myloader没有正确处理metadata中的表信息过滤
2. 元数据中的表信息没有被正确忽略，导致恢复过程陷入等待状态
3. 这个问题在多线程环境下尤为明显，因为线程同步机制可能因此失效

问题复现

开发团队通过简化测试用例确认了这个问题：

-- 创建测试数据库和表
CREATE DATABASE testdb;
USE testdb;
CREATE TABLE a (name text, code int);
CREATE TABLE b (name text, code int);
INSERT INTO a VALUES ('tom', 1), ('sam', 2);
INSERT INTO b VALUES ('dave', 3), ('sarah', 4);

-- 创建第二个测试数据库
CREATE DATABASE testdb1;
USE testdb1;
CREATE TABLE a (name text, code int);
CREATE TABLE b (name text, code int);
INSERT INTO a VALUES ('tom', 1), ('sam', 2);
INSERT INTO b VALUES ('dave', 3), ('sarah', 4);

然后执行备份和恢复命令：

./mydumper -v 3 --clear --threads 4 -o backup -B testdb,testdb1
./myloader -s testdb -d backup -B restoredb -v 3 -o

这个简化测试同样触发了停止问题，确认了问题的普遍性。

解决方案

开发团队已经定位到具体问题并修复了相关代码。修复的核心是确保：

1. 当使用表过滤功能时，正确忽略不需要恢复的表的元数据
2. 保持线程同步机制的正常工作
3. 确保恢复过程的完整性

新版本已经发布，用户只需升级到最新版本即可解决这个问题。

最佳实践建议

为了避免类似问题，建议用户：

1. 定期更新到最新版本的MyDumper/myloader工具
2. 在重要操作前先进行小规模测试
3. 监控恢复过程中的线程状态
4. 对于大型数据库，考虑分批次恢复

这个问题的解决进一步提升了MyDumper/myloader工具的稳定性和可靠性，使其在复杂的数据迁移场景中表现更加出色。