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

场景

某电商平台使用MySQL作为核心交易数据库，PostgreSQL运行分析型业务。近期因数据量激增，备份时间从30分钟延长至4小时，恢复测试耗时超过8小时，严重影响SLA。运维团队需在不影响生产的前提下优化备份恢复性能。

症状

• MySQL：mysqldump耗时剧增，二进制日志堆积，从库复制延迟。
• PostgreSQL：pg_dump导致CPU/IO飙升，pg_basebackup网络传输饱和。
• 通用：磁盘I/O等待接近100%，备份期间业务响应变慢。

诊断

1. 检查备份方法：MySQL是否使用物理备份（如XtraBackup）而非逻辑备份？PostgreSQL是否可启用并行备份？
2. 分析资源利用率：使用iostat, vmstat, top观察CPU、内存和I/O瓶颈。
3. 评估压缩和传输：是否开启压缩？网络带宽是否充足？
4. 检查数据库配置：MySQL的innodb_flush_log_at_trx_commit, sync_binlog；PostgreSQL的wal_level, max_wal_size。

命令

MySQL优化

# 使用Percona XtraBackup进行物理热备（支持并行压缩）
xtrabackup --backup --parallel=4 --compress --compress-threads=4 --target-dir=/backup/mysql

# 恢复时并行解压
xtrabackup --prepare --parallel=4 --target-dir=/backup/mysql
duplicity restore

PostgreSQL优化

# pg_dump使用并行压缩和格式
pg_dump -Fd -j 4 -Z 9 -f /backup/pg_dump mydb

# 使用pgBackRest进行高效物理备份
pgbackrest --stanza=myapp --type=full backup

风险控制

• 备份期间：对MySQL使用--lock-ddl-per-table减少锁竞争；PostgreSQL利用pg_dump的--snapshot实现一致快照。
• 恢复测试：定期在独立环境执行恢复演练，验证RTO/RPO。
• 限流：通过nice或ionice降低备份进程优先级，或使用cgroups限制资源。

回滚

• 若备份导致生产故障，立即终止备份进程。
• MySQL：删除未完成的备份文件，检查从库状态并重新启用同步。
• PostgreSQL：若pg_start_backup()未结束，执行pg_stop_backup()或重启数据库。

验证

1. 数据完整性：pt-table-checksum（MySQL）或pg_checksums（PG）。
2. 恢复时间：记录完整恢复时长，确保符合RTO。
3. 性能基准：对比恢复后的TPS/QPS与基线。

何时提交OpsGlobal工单

• 内部优化后备份恢复仍无法满足SLA。
• 出现数据逻辑损坏或恢复后不一致。
• 需要迁移至专业备份工具（如pgBackRest、MySQL Enterprise Backup）。
• 跨地域异地备份与灾备方案设计。

通过以上方法，该电商平台成功将备份时间缩短至45分钟，恢复时间控制在2小时内。定期性能审查和自动化测试是维持高可用性的关键。