MySQL与PostgreSQL备份恢复性能实战指南

场景

一家SaaS公司计划将核心业务数据库从本地迁移到云端，备份窗口仅2小时。使用MySQL 8.0（InnoDB）和PostgreSQL 15，数据量约500GB。当前备份时间超过3小时，恢复测试时发现恢复时间不可控，影响SLA。

症状

• MySQL: mysqldump 备份耗时3.5小时，恢复用时4小时；使用XtraBackup时备份时间1.5小时，但恢复时磁盘I/O飙升导致其他业务卡顿。
• PostgreSQL: pg_dump 备份耗时2.8小时，恢复时因WAL日志处理慢导致恢复时间超4小时；pg_basebackup 备份时间1.2小时，但恢复时需手动应用WAL。

诊断

MySQL

1. 备份性能瓶颈: 检查mysqldump是否使用--single-transaction（避免锁表）及--quick（逐行输出）。通过perf top发现CPU瓶颈在压缩（默认gzip）。
2. 恢复性能瓶颈: I/O wait高，因mysql < dump.sql单线程执行，且磁盘未使用条带化。

PostgreSQL

1. 备份性能: pg_dump默认串行，使用-j并行参数可提升速度。检查shared_buffers和work_mem设置是否过小。
2. 恢复性能: pg_restore同样串行，需指定-j。WAL归档配置不当导致恢复时需重新应用大量WAL。

命令

MySQL 快速备份（使用XtraBackup）

xtrabackup --backup --parallel=4 --compress --compress-threads=4 --target-dir=/backup/mysql/full

MySQL 恢复

xtrabackup --prepare --target-dir=/backup/mysql/full
xtrabackup --copy-back --target-dir=/backup/mysql/full

PostgreSQL 并行备份

pg_dump -j 4 -Fd -f /backup/pg/dump mydb

PostgreSQL 并行恢复

pg_restore -j 4 -d mydb /backup/pg/dump

风险控制

• 备份前校验磁盘空间，避免写满导致服务中断。
• 生产库使用--single-transaction或--lock-wait-timeout防止长等待。
• 恢复时禁止直接覆盖生产库，先在测试实例验证。
• 对备份文件进行校验和（如SHA256）并定期恢复演练。

回滚方案

• 若新备份失败，立即恢复使用上一个成功备份。
• MySQL: 使用XtraBackup的--incremental-basedir实现增量备份回滚。
• PostgreSQL: 使用PITR（Point-In-Time Recovery）回滚到指定时间点。

验证

1. 恢复完成后运行表级校验和： MySQL: CHECKSUM TABLE table_name; PostgreSQL: 使用pg_surgery（谨慎）或自定义校验工具。
2. 执行关键查询，比较行计数和业务摘要。
3. 监控应用日志，确认无主键冲突或数据丢失。

何时提交OpsGlobal工单

• 备份时间持续超出窗口50%以上。
• 恢复失败或数据不一致，内部无法解决。
• 需要调优备份策略（如选择合适压缩算法、调整并行度）。
• 磁盘或网络I/O瓶颈影响其他工作负载，需要基础设施层支持。

本指南仅提供技术参考，具体操作请遵循贵司的变更管理流程。如需专业协助，请联系OpsGlobal。