MyDumper并行流式备份恢复的性能优化实践

背景概述

MyDumper作为MySQL/MariaDB的高效逻辑备份工具，其流式传输功能(--stream)在大型数据库备份恢复场景中具有独特优势。近期社区用户针对TB级数据库的恢复过程提出了优化需求，特别是在磁盘空间占用和恢复速度方面的改进建议。

核心问题分析

在传统恢复流程中，myloader需要先将整个流式备份解压到临时目录(import-*)后再开始导入，这导致两个显著问题：

1. 临时存储空间需求大（与原始备份同量级）
2. 恢复时间=解压时间+导入时间（串行执行）

关键技术方案

通过深入测试验证，我们总结出以下优化方案：

1. 流式即时恢复模式

使用--overwrite-unsafe参数可实现"边解压边导入"的流水线作业：

restic dump latest mariadb.sql | myloader --overwrite-unsafe --stream --threads $(nproc)

该模式下：

• 解压线程与导入线程并行工作
• 临时文件随导入完成立即删除
• 内存消耗稳定，磁盘空间占用最小化

2. 备份参数优化建议

• 设置合理的分块大小：--chunk-filesize 50M（过大会降低并行度）
• 启用ZSTD压缩：-c ZSTD（减少I/O压力）
• 匹配服务器核心数：--threads $(nproc)

3. 数据库端优化

• 临时调大InnoDB缓冲池
• 关闭二进制日志(binlog)
• 禁用外键检查(SET FOREIGN_KEY_CHECKS=0)
• 调整事务提交频率(innodb_flush_log_at_trx_commit)

性能对比测试

在32vCPU/128GB RAM的GCP实例上测试600GB数据库：

恢复模式	临时空间	总耗时	CPU利用率
传统串行模式	600GB	14h	波动较大
并行流式恢复	<1GB	11h	持续高位

注意事项

1. --overwrite-unsafe可能导致外键死锁，建议在维护窗口期使用
2. 流式恢复对网络稳定性要求较高，建议在可靠内网环境实施
3. 超大表建议单独处理，避免成为性能瓶颈

进阶建议

对于专业DBA团队，可考虑：

• 开发自定义缓冲区管理（调整stream_buffer_size）
• 实现优先级调度（先导入小表后大表）
• 结合数据库物理备份做混合恢复

通过本文介绍的优化方法，用户可显著提升大规模数据库的恢复效率，同时降低对临时存储的需求，为关键业务系统提供更可靠的数据保障能力。