MyDumper/myloader 流式传输中的文件大小不一致问题分析

问题背景

在使用MyDumper/myloader进行数据库备份和恢复时，用户报告了一个关于流式传输模式下文件大小不一致的问题。具体表现为在v0.16.11-1版本中，myloader会报错"Stream failed during transmition of file"并显示文件大小不匹配，而回退到v0.13.1-1版本则能正常工作。

问题现象

用户在使用流式传输模式(--stream)时遇到以下典型错误：

1. 文件传输失败错误："Stream failed during transmition of file"
2. 文件大小不匹配日志："Different file size in [filename]. Should be: X | Written: Y"
3. 内存分配失败错误："failed to allocate 140737488355328 bytes"
4. 管道断裂错误："stdout: Broken pipe"

问题复现条件

该问题在以下配置下可稳定复现：

• MyDumper/myloader版本：v0.16.11-1
• 操作系统：Ubuntu 24.04 LTS
• 数据库规模：约100GB，包含多张表
• 使用参数组合：--compress + --chunk-filesize + --stream

技术分析

流式传输机制

MyDumper的流式传输模式通过管道(|)将备份数据直接传输给myloader进行恢复，无需中间文件存储。这种模式下，数据压缩(--compress)和分块(--chunk-filesize)功能可能会引入额外的复杂性。

问题根源

经过分析，该问题主要由以下几个因素导致：

1. 版本兼容性问题：v0.16.11-1版本在流式传输处理逻辑上存在缺陷，特别是在处理压缩数据块时可能出现缓冲区管理不当的情况。

2. 内存管理缺陷：当同时启用压缩和分块功能时，程序尝试分配异常大的内存(140737488355328 bytes)，这明显是内存计算错误导致的。

3. 管道同步问题：在高速流式传输过程中，生产者和消费者之间的同步机制可能存在缺陷，导致数据完整性校验失败。

解决方案

临时解决方案

1. 降级使用v0.13.1-1版本：这是最直接的解决方案，该版本不存在此问题。

2. 分离执行流程：将备份和恢复分为两个独立步骤：

   mydumper [参数] > backup.sql
   myloader [参数] < backup.sql
   

3. 调整参数组合：避免同时使用--compress和--chunk-filesize参数。

长期解决方案

开发团队已经确认该问题并提供了修复分支(fix_1687)。用户可以直接使用该分支代码进行编译安装，该修复主要涉及：

1. 修正了流式传输中的数据校验逻辑
2. 优化了内存分配机制
3. 改进了压缩数据块的处理流程

最佳实践建议

1. 对于大型数据库备份恢复，建议先进行小规模测试验证
2. 考虑使用--max-threads-for-schema-creation=1参数避免可能的死锁问题
3. 监控系统资源使用情况，特别是内存和管道缓冲区
4. 保持工具版本更新，及时应用官方修复

总结

MyDumper/myloader作为高效的MySQL备份恢复工具，其流式传输模式在特定版本和参数组合下可能出现文件大小不一致的问题。通过理解问题本质并采取适当的解决方案，用户可以顺利完成数据库迁移任务。开发团队正在积极修复相关问题，建议用户关注官方更新以获取稳定版本。