MyDumper大表导出时myloader卡死问题分析与解决方案

问题现象

在使用MyDumper进行数据库备份恢复时，用户遇到了一个棘手的问题：当使用myloader导入包含超大表（3TB数据库，其中2.7TB为单表）的备份时，导入进程会在某个点卡住不再继续。通过性能分析工具perf采集的数据显示，进程99%的时间都消耗在cmp_restore_job函数中。

问题分析

深入分析代码后发现，这个问题很可能与MyDumper的分块导出机制有关。用户使用了--rows=1000000参数对大表进行分块导出，这会生成大量数据文件。在myloader恢复过程中，处理这些分块文件时可能出现以下问题：

1. 文件排序比较函数问题：cmp_restore_job函数负责对恢复任务进行排序，当分块文件数量极大时，排序过程可能出现异常。

2. 整数溢出风险：代码中对分块编号(part)的处理可能存在整数溢出问题，特别是当分块数量非常大时。

3. 资源竞争：64个线程并发处理大量小文件可能导致锁竞争加剧。

解决方案

经过验证，有以下几种可行的解决方案：

1. 增大分块行数：将--rows参数从100万增加到2000万，显著减少了分块文件数量。实际测试表明，这一调整有效避免了卡死问题。

2. 使用最新版本：MyDumper最新版本已实现自动动态调整分块行数的功能，特别是对于有整数主键的大表，无需手动指定--rows参数。

3. 优化线程配置：对于超大表恢复，可适当减少并发线程数，避免资源竞争。

最佳实践建议

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

1. 优先使用MyDumper最新版本，利用其自动分块优化功能。

2. 如需手动控制分块大小，应根据表数据量合理设置--rows参数，避免生成过多小文件。

3. 监控恢复过程中的资源使用情况，必要时调整线程数等参数。

4. 对于特别大的表，考虑单独处理或采用其他备份策略。

这个问题展示了在数据库备份恢复工具中处理极端场景时可能遇到的挑战，也体现了参数调优在性能优化中的重要性。通过合理配置，可以确保MyDumper/myloader在处理超大规模数据时保持稳定高效。