大库为什么换思路
数据量上到几十 GB 之后，逻辑导出会同时暴露三个问题：导出窗口长到影响业务、恢复时单线程重放慢在索引维护上、备份文件占用的空间与带宽难以为继。这时要把「备份」和「恢复」当成一个整体来选型：物理备份牺牲灵活性换恢复速度，逻辑备份保留灵活性但只适合中小规模。
基本信息
| 适用平台 | MySQL 5.7 / 8.0 的备份方案选型 |
|---|---|
| 逻辑备份 | mysqldump、mydumper、MySQL Shell dump（可并行） |
| 物理备份 | Percona XtraBackup、MySQL Enterprise Backup |
| 关键取舍 | 备份时长 vs 恢复时长 vs 文件灵活性 |
| 窗口估算 | 恢复耗时通常是备份耗时的 1.5-3 倍 |
典型使用场景
- 库体积超过百 GB，逻辑导出窗口已经无法排进维护期
- 主库不允许长时间承担备份压力，改为从从库执行导出
- 需要在有限维护窗口内完成恢复，物理备份更有优势
- 分区表场景：按分区滚动备份与归档，缩小单次备份粒度
- 跨环境搭建测试库时，用压缩的逻辑导出更便于筛选与裁剪
规模与手段对照
| 数据规模 | 推荐手段 | 备注 |
|---|---|---|
| 小于 50 GB | mysqldump 或 mydumper | 注意加 --single-transaction 保证一致性 |
| 50-500 GB | mydumper 或 MySQL Shell dump | 并行导出，压缩后传输 |
| 大于 500 GB | XtraBackup 等物理备份 | 恢复快，需要 prepare 步骤 |
| 超大单表 | 分区表按分区处理 | 配合归档策略降低单次容量 |
| 只读业务库 | 从从库执行备份 | 先确认复制无延迟 |
从从库备份与并行导出
从从库备份与并行导出
set -euo pipefail
# 在从库上执行，分摊主库压力（务必先确认复制延迟为 0）
mysqldump -h replica-01 -u backup -p \
--single-transaction --source-data=2 --all-databases \
| zstd -3 > /data/backup/all_$(date +%F).sql.zst
# 并行逻辑导出（mydumper）
mydumper -h replica-01 -u backup -p -t 4 -c -o /data/backup/full_$(date +%F)
# 物理备份（XtraBackup 全量）
xtrabackup --backup --target-dir=/data/backup/xtra_$(date +%F) --host=replica-01评估维护窗口时把恢复时间作为上限：物理备份还需要一个 prepare 步骤，逻辑恢复要重建索引与回放，实测一次比按经验估算更可靠。
从从库备份前先确认 Seconds_Behind_Source 为 0 且复制线程正常：备份到的是延迟数据本身不算问题，真正危险的是复制中断却没人发现，备出来的是一份过期的快照。