优化生产环境中MySQL和PostgreSQL的备份与恢复性能

场景

某电商平台使用2TB PostgreSQL和500GB MySQL数据库。备份作业通常需数小时，且恢复时间目标（RTO）经常超标。备份期间，数据库响应变慢，影响业务。

症状

• 备份持续时间不断增长，从30分钟增加到2小时。
• 系统监控显示备份期间磁盘I/O等待率高达90%。
• 恢复演练中，从备份集恢复1TB数据耗时超过预定RTO（4小时）。

诊断

PostgreSQL

• 使用pg_stat_replication查看WAL积压。
• 检查pg_stat_bgwriter的checkpoint相关统计。
• 使用htop或iostat监控I/O。

MySQL

• 使用SHOW ENGINE INNODB STATUS\G查看日志序列号（LSN）和检查点。
• 使用performance_schema的file_summary_by_instance识别高I/O文件。

命令与参数调优

PostgreSQL备份优化

# 使用pg_basebackup并开启压缩和多线程
pg_basebackup -h localhost -U replicator -D /backup -Ft -z -P --wal-method=stream --compress=9 --workers=4 --max-rate=100M

调整参数（postgresql.conf）： - wal_compression = on - checkpoint_completion_target = 0.9 - max_wal_senders = 10（增加WAL发送者）

MySQL备份优化

# 使用Percona XtraBackup并行备份
xtrabackup --backup --target-dir=/backup --parallel=4 --compress --compress-threads=4

调整参数（my.cnf）： - innodb_buffer_pool_size设为物理内存的70%，避免I/O颠簸。 - innodb_log_file_size增大至4GB减少日志切换。 - 调整innodb_io_capacity以配合磁盘性能。

风险控制

• 始终从副本（从库）进行备份，避免主库压力。
• 使用ionice或cgroups限制备份进程的I/O优先级。
• 备份前确保系统资源（CPU、内存、磁盘）充足，预留20%空闲。

回滚与验证

回滚

如果备份失败或产生损坏，立即停止并清理临时文件。使用以下命令恢复上一个可用全备：

# PostgreSQL
pg_ctl start -D /data -o '-P 1' # 进入offline模式恢复
# MySQL
systemctl stop mysql
cp -r /backup/latest /var/lib/mysql
chown -R mysql:mysql /var/lib/mysql
systemctl start mysql

验证

• 恢复后运行数据校验：pg_checksums -c -D /data（PG）；MySQL使用mysqlcheck -A。
• 执行基准查询测试响应时间。

何时提交OpsGlobal工单

• 当环境包含混合云或复杂网络拓扑，无法自行优化备份网络带宽。
• 数据库大小超过5TB且现有工具无法满足RTO。
• 备份恢复过程中出现数据不一致或反复失败，需专家介入排查。

OpsGlobal提供7x24小时远程SRE支持，协助您设计高效备份策略并解决性能瓶颈。