场景

您的组织在 Kubernetes 中运行 MySQL 和 PostgreSQL 数据库。夜间备份任务超出了维护窗口，故障恢复演练也经常无法满足 RTO 要求。原本只需几分钟的恢复现在要耗上几个小时。本文基于一次真实运维工作，介绍如何优化这两个数据库引擎的备份和恢复性能。

症状

• mysqldump 或 pg_dump 任务运行超过 4 小时。
• 使用 XtraBackup 或 pg_basebackup 的物理备份产生高 I/O，导致生产环境延迟飙升。
• 恢复（restore）时间远大于备份时间。
• 备份期间事务日志意外增长。
• 监控显示备份主机 CPU 接近 100%，但数据库节点却处于空闲状态。

诊断

检查使用的是逻辑备份还是物理备份： - 逻辑备份（mysqldump、pg_dump）是 CPU 密集型的，对于大数据集效率较低。 - 物理备份（XtraBackup、pg_basebackup）直接复制原始文件，属于 I/O 密集型，但需要仔细调优。

对于 MySQL： 1. 检查 innodb_buffer_pool_size：如果太小，XtraBackup 会更多地从磁盘读取。 2. 检查备份工具的并行性：XtraBackup --parallel=N 可加快数据文件传输。 3. 考虑使用 --compress 减少网络传输，但会增加 CPU 开销。 4. 分析 I/O 能力：顺序读写应与存储类型对齐。

对于 PostgreSQL： 1. pg_basebackup 通过复制协议发送整个数据目录；使用 --jobs=N 进行并行传输。 2. wal_level=replica 和 max_wal_senders 必须足够高，以支持备份和复制。 3. 检查 archive_timeout 和 archive_command：如果太低，WAL 文件会累积。 4. 使用 pgBackRest 等工具，它支持加密、压缩和并行上传。

命令

MySQL 使用 Percona XtraBackup

# 物理备份，带并行和压缩
xtrabackup --backup --parallel=8 --compress --compress-threads=4 --target-dir=/backup/mysql

# 准备备份（也可并行）
xtrabackup --prepare --parallel=8 --target-dir=/backup/mysql

# 增量备份（假设已存在全量备份）
xtrabackup --backup --parallel=8 --incremental-basedir=/backup/mysql/base --target-dir=/backup/mysql/inc

# 从全量 + 增量恢复
xtrabackup --prepare --apply-log-only --target-dir=/backup/mysql/base
xtrabackup --prepare --apply-log-only --incremental-dir=/backup/mysql/inc --target-dir=/backup/mysql/base
xtrabackup --prepare --target-dir=/backup/mysql/base

PostgreSQL 使用 pg_basebackup

# 并行物理备份
pg_basebackup -h primary-host -D /backup/pgsql -U replicator -Ft -z -j 8 -X stream

# 从基础备份恢复
tar -xzf /backup/pgsql/base.tar.gz -C /var/lib/postgresql/16/main
tar -xzf /backup/pgsql/pg_wal.tar.gz -C /var/lib/postgresql/16/main/pg_wal
touch /var/lib/postgresql/16/main/recovery.signal

风险控制

• 始终对备份进行限速：对 XtraBackup 使用 --throttle 或用 ionice 限制备份进程。
• 从副本执行备份，避免生产负载。
• 对于物理备份，确保有足够的磁盘空间；压缩可减少空间占用，但会增加 CPU。
• 定期使用 XtraBackup 的 --verify-backup 和 pg_verifybackup 来验证备份完整性。
• 保留多个 WAL/归档副本；使用独立存储避免单点故障。

回滚

如果性能调优导致不稳定： - 将 innodb_buffer_pool_size 和备份并行度恢复为之前的值。 - 对于 PostgreSQL，将 max_wal_senders 或 archive_command 恢复为原始设置。 - 如果恢复失败，记录错误并回退到最后一个已知的正常备份。 - 始终保留上一组备份，直到新备份完全验证通过。

验证

• 使用 time 测量改动前后的备份和恢复时间。
• 通过恢复到预发布实例并运行 MySQL 的 CHECKSUM TABLE 或 PostgreSQL 的 pg_checksums --enable 来验证备份。
• 比较记录计数和增量日志序列号。
• 监控备份窗口期间的 I/O 延迟和 CPU 使用率。

何时提交 OpsGlobal 工单

如果您的团队缺乏 xtrabackup 或 pgBackRest 调优经验，或者按照本指南操作后瓶颈仍然存在，请联系 OpsGlobal。我们的 SRE 团队可以执行备份评估、实施灾难恢复自动化，并运行混沌测试，确保 RTO/RPO 合规。