优化 MySQL 和 PostgreSQL 的备份恢复性能

场景

您的生产 MySQL 或 PostgreSQL 数据库崩溃。您从备份开始恢复，但恢复时间比预期长得多，导致停机时间延长和收入损失。当备份策略未针对性能进行优化时，此场景很常见。

症状

• 恢复吞吐量低于预期磁盘吞吐量。
• 恢复期间 I/O 等待高。
• 数据库日志显示检查点或 WAL 回放缓慢。
• CPU 利用率低但 I/O 饱和。

诊断

MySQL

• 使用 SHOW PROCESSLIST 识别正在运行的查询。
• 检查 InnoDB 状态：SHOW ENGINE INNODB STATUS\G 查看历史列表长度、日志序列号。
• 使用 iostat -x 1 监控 I/O。
• 通过慢查询日志分析恢复期间的慢查询。

PostgreSQL

• 查询 pg_stat_activity 获取活动恢复进程。
• 使用 pg_stat_bgwriter 和 pg_stat_wal 跟踪检查点和 WAL 活动。
• 检查 pg_current_wal_lsn 和复制延迟（如果适用）。
• 如果启用 pg_stat_statements，识别开销大的查询。

命令

MySQL

• 备份：xtrabackup --backup --target-dir=/backup
• 恢复：xtrabackup --prepare --target-dir=/backup 然后 xtrabackup --copy-back --target-dir=/backup
• 调优 InnoDB：SET GLOBAL innodb_buffer_pool_size = RAM的80%；SET GLOBAL innodb_log_file_size = 4G；
• 并行恢复：使用 mysqlpump 的 --parallel-schemas 或带线程的 mydumper。

PostgreSQL

• 备份：pg_dump -Fc -d dbname > db.dump
• 恢复：pg_restore -d dbname -j 4 db.dump（并行作业）
• 调优：ALTER SYSTEM SET maintenance_work_mem = '2GB'；ALTER SYSTEM SET max_parallel_maintenance_workers = 4；
• 检查点：CHECKPOINT； 和 pg_switch_wal();

风险控制

• 始终在预演环境测试恢复。
• 使用压缩和加密的备份以减少 I/O，但要管理 CPU 开销。
• 监控磁盘性能，考虑使用 SSD。
• 对于大型数据库，使用增量备份以减少恢复时间。
• 实施时间点恢复（PITR），使用 MySQL 的二进制日志和 PostgreSQL 的 WAL。
• 设置适当的 innodb_buffer_pool_size 或 shared_buffers，避免磁盘抖动。

回滚

如果恢复失败或超时： 1. 停止恢复进程。 2. 验证备份文件完整性。 3. 如果可用，从其他备份点恢复。 4. 如果检测到损坏，从完整备份恢复并应用日志。 5. 通知团队并考虑升级到 OpsGlobal。

验证

• 在 MySQL 中运行 CHECKSUM TABLE，或在 PostgreSQL 中使用 pg_checksums。
• 比较行数和预期值。
• 运行几个查询验证应用程序功能。
• 如果使用副本，检查复制状态。

何时提交 OpsGlobal 工单

• 您的备份/恢复始终超过 RTO 的 50% 以上。
• 恢复期间出现无法解释的性能下降。
• 需要调整数据库参数以优化恢复。
• 需要全面的备份策略审查。