SQL 灾备系统的设计思路

主从复制不是灾备，仅是高可用基础；真正灾备需满足异地、离线、可验证三条件，须依赖物理备份+xtrabackup+binlog归档，并定期演练验证。

主从复制不是灾备，只是高可用基础

很多人把 MySQL 主从同步当成“灾备”，其实它连 RPO=0 都做不到：网络抖动、主库崩溃未刷盘、从库延迟都可能导致数据丢失。真正的灾备必须满足异地、离线、可验证三个条件。

实操建议：

• 主从仅用于读写分离和短时故障转移，binlog_format 必

  

  须设为 ROW，否则 DDL 或非确定性函数会导致从库数据不一致
• 从库开启 read_only=ON 和 super_read_only=ON，防止误写入污染复制链路
• 用 pt-heartbeat 或 SHOW REPLICA STATUS 中的 Seconds_Behind_Master（注意：MySQL 8.0.22+ 已改名 Seconds_Behind_Source）持续监控延迟，超过 60 秒应告警

物理备份 + WAL 归档才是核心灾备路径

逻辑备份（mysqldump）恢复慢、无法精确到秒、不支持大库（>100GB 易超时或锁表），而物理备份（如 xtrabackup）配合 binlog 流式归档，才能实现 RPO

关键配置与陷阱：

• xtrabackup 全量备份需在低峰期执行，并用 --no-lock（仅适用于 InnoDB 且无 DDL）；否则必须加 --lock-ddl，否则备份期间 DDL 可能导致不一致
• binlog 必须开启 log_bin、expire_logs_days=7（至少保留 7 天），并用 mysqlbinlog --read-from-remote-server 实时拉取到异地存储（如 S3 / OSS）
• 备份文件本身要打时间戳 + 校验码：sha256sum backup_20260124_0200.xbstream > backup_20260124_0200.sha256，避免介质损坏后才发现不可用

灾备库不能只“挂着”，必须定期演练还原

90% 的灾备失败发生在“第一次真正切换时”——因为备份没校验、权限缺失、时区/字符集不一致、或者 my.cnf 中漏配 innodb_log_file_size 导致启动失败。

最低成本验证方式：

• 每周自动解压一份全量备份 + 应用最近 2 小时 binlog 到隔离环境，跑 SELECT COUNT(*) 对比主库关键表行数（误差 > 0.1% 即告警）
• 灾备实例必须使用独立账号，禁止复用主库 root；连接串中显式指定 time_zone='+00:00' 和 character_set_server=utf8mb4
• 所有还原脚本必须带 dry-run 模式，例如 xtrabackup --prepare --dry-run 提前暴露日志文件缺失问题

跨机房网络不可信，得靠异步+幂等+断点续传

主库到灾备中心的链路常有丢包、带宽限速、防火墙重置连接。直接 rsync 或 scp 传输备份会中断即失败，必须设计容错传输层。

推荐组合方案：

• 用 rclone 同步到对象存储，配置 --transfers=4 --retries=10 --low-level-retries=20，失败自动重试且支持断点
• binlog 归档进程用 systemd 管理，启用 Restart=on-failure 和 StartLimitIntervalSec=600，防止单次崩溃导致归档停滞
• 灾备端拉取脚本中加入幂等判断：先 ls -t /backup/binlog/*.00000* | head -n1 获取最新位点，再对比远程 SHOW BINARY LOGS 结果，跳过已存在文件

灾备最易被忽略的不是技术，而是“谁在什么时候触发哪一步”。没有明确的《灾备切换 SOP》和每季度一次的无通知演练，再好的架构也只是纸面 RTO。