MyDumper导入过程中cmp_restore_job函数卡死问题分析与解决方案

问题现象

在使用MyDumper工具进行数据导入时，用户遇到了myloader进程卡死的情况。具体表现为myloader进程长时间停滞不前，CPU占用显示其大部分时间都消耗在cmp_restore_job函数中。该问题发生在MyDumper 0.16.8版本上，导入的是一个包含3TB数据的数据库，其中2.7TB来自单个大表。

问题分析

通过性能分析工具perf的输出可以看出，myloader进程88.7%的时间都消耗在cmp_restore_job函数中。这个函数是myloader用来比较和恢复作业的核心函数，其内部实现包含一个while循环，用于处理数据导入任务。

深入分析代码后发现，当使用--rows参数设置较小的分块大小时（如1000000行），对于超大表会产生大量数据文件。这可能导致以下问题：

1. 整数溢出风险：在处理大量分块文件时，part变量可能发生溢出
2. 性能瓶颈：过多的文件会增加比较和调度的开销
3. 资源竞争：64个线程并发处理大量小文件可能导致锁竞争

解决方案

经过测试验证，以下解决方案可以有效解决该问题：

1. 增大分块大小：将--rows参数从1000000增加到20000000，显著减少了文件数量
2. 使用最新版本：新版本MyDumper已实现自动调整分块大小的功能，无需手动设置--rows参数
3. 优化线程配置：适当减少并发线程数，避免资源竞争

最佳实践建议

对于包含超大表的数据库备份和恢复，建议：

1. 优先使用MyDumper最新版本，利用其自动分块优化功能
2. 如果必须手动设置--rows参数，应根据表大小合理设置，避免产生过多小文件
3. 监控导入过程中的资源使用情况，特别是CPU和内存
4. 对于特别大的表，考虑单独处理或使用其他优化策略

该问题的解决不仅提高了MyDumper工具的稳定性，也为处理超大规模数据库提供了实践经验。通过合理的参数配置和版本选择，可以有效避免类似问题的发生。