提升 MySQL 和 PostgreSQL 备份恢复性能：SRE 实用指南

场景

OpsGlobal 的一位客户在 Kubernetes 上运行 MySQL 和 PostgreSQL，备份到对象存储。最近，备份作业的耗时不断增加，恢复过程甚至需要数小时，导致恢复时间目标（RTO）面临风险。客户希望在不影响生产性能的前提下，加快备份和恢复速度。

症状

• 备份作业运行时间从 30 分钟增加到 2 小时以上。
• 备份期间的 CPU 和 I/O 使用率飙升，影响在线业务。
• 恢复测试表明，从备份中恢复数据库需要超过 4 小时。
• 用户报告查询响应变慢，尤其是在备份任务执行时。

诊断

首先，我们收集性能基线。使用 top、iostat、vmstat 等工具监控系统资源，并查看数据库的慢查询日志和状态变量。

对于 MySQL，我们检查 SHOW ENGINE INNODB STATUS 以及 performance_schema 中的等待事件。对于 PostgreSQL，我们依赖 pg_stat_statements 和 pg_stat_activity。

关键指标包括： - 备份工具的吞吐量（MB/s） - 压缩率 - 网络带宽利用率 - 目标存储的写入延迟

通过分析，我们发现备份工具使用的是默认的串行模式，没有利用多核 CPU；同时，备份过程中未进行限流，导致 I/O 竞争激烈。

命令与优化

MySQL（使用 XtraBackup）

使用 xtrabackup 时，启用并行备份可以显著提升速度：

xtrabackup --backup --parallel=4 --target-dir=/backup/mysql \
  --throttle=100 --compress --compress-threads=4

• --parallel 控制复制 InnoDB 文件时的并行线程数。
• --throttle 限制每秒写入的 I/O 操作数，避免影响生产。
• --compress-threads 启用并行压缩。

PostgreSQL（使用 pg_basebackup）

pg_basebackup 支持速率限制和并行压缩：

pg_basebackup -h localhost -U replicator -D /backup/pg \
  --max-rate=100M --compress=zstd:3 --pgdata /backup/pg \
  --wal-method=stream

• --max-rate 限制备份的最大传输速率。
• --compress 使用 zstd 压缩，zstd:3 表示压缩级别。

此外，调整数据库参数以优化恢复性能： - MySQL：增大 innodb_buffer_pool_size 和 innodb_log_file_size，在恢复期间可暂时调大 innodb_flush_log_at_trx_commit。 - PostgreSQL：调整 max_wal_senders、wal_keep_size，并考虑使用 recovery_parallelism（PostgreSQL 16+）。

风险控制

• 在执行备份性能调优前，先在预生产环境验证。
• 始终使用限流参数，避免备份压垮生产存储。
• 确保备份文件加密和传输安全，但注意加密也会消耗 CPU。
• 使用增量备份或物理备份减少数据量。
• 监控备份完成后立即进行恢复演练，确认备份可用。

回滚

如果调整导致问题（如备份失败或性能下降），请执行以下回滚步骤： 1. 恢复原始备份脚本或参数。 2. 如果使用了 pg_basebackup 的压缩参数，需确保目标版本支持。 3. 重启数据库服务（如适用）以清除配置变更。 4. 重新运行备份测试，验证性能是否回到基线。

验证

1. 进行恢复测试，测量从备份恢复到新实例的实际时间。
2. 使用 mysqlbinlog 或 PostgreSQL 的 pg_verifybackup 校验备份的完整性。
3. 在恢复过程中监控资源消耗，确保不会出现资源饥饿。
4. 对比优化前后的 RTO，确认达到目标。

何时提交 OpsGlobal 工单

如果您的团队缺乏数据库内部调优经验，或者备份恢复问题涉及复杂的高可用架构，请提交工单给 OpsGlobal。我们提供 24/7 的 SRE 支持，可以帮助您设计备份策略、优化性能并执行恢复演练，确保您的数据安全。