Mydumper/myloader 导入过程中卡在读取元数据问题的分析与解决

问题现象

在使用Mydumper/myloader工具进行MySQL数据库迁移时，用户报告了一个常见问题：当从RDS MySQL 8.0导出数据并导入到Aurora数据库时，myloader进程会在"Reading metadata: metadata"阶段长时间挂起，CPU占用率达到100%。这个问题尤其在大规模数据库(如包含42,000张表)迁移时更为明显。

问题分析

通过深入分析，我们发现问题的根源在于myloader处理元数据的方式存在性能瓶颈。具体表现为：

1. 元数据处理机制缺陷：当schema创建文件(<SCHEMA_NAME>-schema-create.sql)不存在时，myloader会不断重试导入表数据，导致进程挂起。

2. 大规模表处理性能问题：在处理包含大量表(如22,705张表)的元数据文件时，myloader会在refresh_table_list_without_table_hash_lock函数中陷入性能瓶颈。该函数使用g_list_insert_sorted对表列表进行排序，当表数量庞大时，排序操作会消耗大量CPU资源。

3. 元数据文件内容：分析发现元数据文件中只包含表信息，缺少schema创建语句，这导致myloader无法正确识别和创建目标schema。

解决方案

项目维护者已针对此问题发布了修复方案：

1. 版本升级：建议用户升级到v0.16.2-3或更高版本，该版本包含了针对此问题的修复。

2. 元数据处理优化：新版本改进了myloader的行为，当schema不存在时，会重新排队作业而不是直接跳过。如果重试后schema仍然不存在，才会认为schema已存在并继续导入表数据。

3. 性能改进：针对大规模表处理的性能问题，维护者计划进一步优化myloader的元数据处理逻辑，避免在大规模表场景下的性能下降。

最佳实践建议

对于需要进行大规模数据库迁移的用户，我们建议：

1. 预先创建schema：在导入数据前，先手动创建所有需要的schema，可以避免schema不存在导致的问题。

2. 分批处理：对于超大规模数据库，考虑按schema分批导出和导入数据，减少单次操作的表数量。

3. 监控资源使用：在导入过程中监控系统资源使用情况，特别是CPU和内存使用率。

4. 版本选择：始终使用最新稳定版本的mydumper/myloader工具，以获得最佳性能和稳定性。

总结

Mydumper/myloader作为MySQL数据库迁移的重要工具，在处理大规模数据库时可能会遇到性能瓶颈。通过理解工具的工作原理和潜在问题，用户可以更有效地规划和管理数据库迁移任务。项目维护团队持续改进工具性能，为用户提供更稳定高效的数据库迁移体验。