管道式备份的定位
mysqldump 把数据导成 SQL 文本，体积通常是原库数据的两三倍甚至更多，直接落盘既占空间也占带宽。接一个压缩进程或直接管道传到备机，就能在导出过程中同步完成压缩或远程落盘，全程不产生中间明文文件。代价是管道中任何一段失败都可能被后面的命令掩盖，必须显式打开 pipefail 才能捕获。
基本信息
| 适用平台 | Linux/Unix shell；MySQL 5.7 / 8.0 的 mysqldump |
|---|---|
| 压缩写法 | mysqldump ... | gzip > backup.sql.gz |
| 恢复写法 | zcat backup.sql.gz | mysql ... |
| 直传写法 | mysqldump ... | mysql -h 备机 |
| 一致性前提 | InnoDB 表加 --single-transaction 获得一致性快照 |
| 防护手段 | set -o pipefail 捕获管道任意一段的失败 |
典型使用场景
- 磁盘紧张的小中型库：压缩后体积常降到原来的三分之一左右
- 备份直接归档到对象存储或远端机器，本地不落明文文件
- 主库导出后直连备机导入，用于临时搭测试库
- 例行巡检前先做一份快照，用于比对前后数据变化
- 跨环境搬数据：本地导出压缩后传到隔离网络中的实例
压缩备份与恢复
压缩备份与恢复
set -euo pipefail # 任一段失败立即退出
OUT=/data/backup/all_$(date +%F).sql.gz
# --single-transaction 保证 InnoDB 一致性，--source-data=2 记录位点
mysqldump -uroot -p --single-transaction --source-data=2 --all-databases \
| gzip -6 > "$OUT"
ls -lh "$OUT" # 看体积是否在预期范围
zcat "$OUT" | head -20 # 确认开头是可读的 SQL 文本
zcat "$OUT" | mysql -uroot -p # 恢复（先在建好的测试实例上验证）压缩工具对照
| 工具 | 特点 | 适用场景 |
|---|---|---|
| gzip | 单线程，兼容性最好 | 通用备份，CPU 余量充足 |
| pigz | gzip 的多线程实现，参数基本兼容 | 多核机器上压缩大库提速 |
| zstd | 压缩比与解压速度更好 | 长期归档、需要快速恢复 |
| lz4 | 压缩速度极快、比值较低 | 备份窗口紧张时优先考虑 |
默认 shell 下管道只有最后一条命令的退出码有意义：gzip 因磁盘写满失败时，整条命令仍可能返回 0，备份静默损坏。任何管道式备份都要加 set -o pipefail。
恢复前先确认源文件完整（结尾应有 Dump completed 行）并验证压缩包可解：zcat 报错即说明文件被截断，此时导入只会得到半截数据。