场景

在生产环境中，MySQL 和 PostgreSQL 数据库的备份与恢复操作经常遇到性能瓶颈，导致备份窗口过长或恢复时间远超预期。尤其在 Kubernetes 上运行时，存储、网络、资源限制等因素会加剧问题。

症状

• 备份耗时增加，超过业务容忍窗口。
• 恢复操作缓慢，例如从 500GB 备份恢复耗时超过 6 小时。
• 系统监控显示高 I/O 等待、CPU 使用率低但磁盘延迟高。
• 备份工具（如 pg_dump、XtraBackup）报错或超时。

诊断

1. 检查资源使用： bash kubectl top pods -n database 查看 CPU 和内存是否受限。
2. 分析 I/O 性能： bash iostat -x 1 观察 %util 和 await 指标。
3. 数据库内部诊断： - MySQL： sql SHOW ENGINE INNODB STATUS\G; 关注适应哈希索引和日志等待。 - PostgreSQL： sql SELECT * FROM pg_stat_activity WHERE state = 'active'; 查找长时间运行的查询。
4. 查看备份工具日志： - XtraBackup：检查 xtrabackup_log。 - pg_dump：使用 --verbose 参数。

命令

MySQL 备份优化

• 使用并行备份： bash xtrabackup --backup --parallel=4 --target-dir=/backup
• 压缩备份： bash xtrabackup --backup --compress --compress-threads=4 --target-dir=/backup
• 限速：避免对生产影响： bash xtrabackup --backup --throttle=100 --target-dir=/backup

PostgreSQL 备份优化

• 使用目录格式（支持并行）： bash pg_dump -Fd -j 4 -f /backup mydb
• 压缩： bash pg_dump -Fc -Z 9 -f /backup/dump.gz mydb
• 选择性备份：排除大表或无用的索引。

恢复优化

• MySQL：使用 --apply-log 和 --use-memory 加速重放： bash xtrabackup --prepare --use-memory=4G --target-dir=/backup
• PostgreSQL：恢复时增加 maintenance_work_mem： sql SET maintenance_work_mem = '1GB'; 并使用并行恢复（若支持）。

风险控制

• 在低峰期执行备份。
• 使用 I/O 限速（throttle）防止影响在线业务。
• 将备份存储到独立存储卷，避免与数据库争用。
• 先在小规模测试环境验证恢复速度。

回滚

• 若备份参数导致失败，恢复到默认参数（如取消并行）。
• 若恢复操作产生错误数据，立即停止并恢复最近的快照或全量备份。

验证

• 恢复后运行一致性检查：
• MySQL：checksum table 或 pt-table-checksum。
• PostgreSQL：pg_checksums 或 ANALYZE。
• 监控业务查询是否正常返回。

何时提交 OpsGlobal 工单

• 备份或恢复时间持续超出 SLA（如超过 4 小时）。
• 发生数据损坏或恢复失败。
• 需要架构层面的优化建议（如调整存储类型、数据库参数）。
• 不确定风险控制的配置。

通过以上步骤，大部分性能问题可自行解决。若问题顽固，OpsGlobal 的 SRE 团队可提供深度分析与优化。