深色模式
数据库容灾与异地多活基础
摘要：容灾先量化两个指标：RPO（能接受丢多少数据）与 RTO（多久必须恢复）。本文按「同城双活/异地灾备」层次给出备份异地留存、跨机房复制与切换预案的实施要点。
适用环境
bash
# 确认当前架构与延迟水位
mysql -uroot -p -e "SHOW REPLICA STATUS\G" | grep -E 'Seconds_Behind'
# 机房间网络延迟（决定同步方案）
ping -c 5 10.1.0.10 # 灾备机房地址1
2
3
4
2
3
4
操作步骤
1. 先量化目标
| 等级 | RPO | RTO | 典型方案 |
|---|---|---|---|
| 冷备 | 小时级（依备份周期） | 数小时 | 备份异地留存 |
| 温备 | 分钟级 | 数十分钟 | 异地从库 + 备份 |
| 热备 | 秒级 | 分钟级 | 跨机房半同步/集群 |
| 多活 | 0 | 秒级 | 单元化 + 双向同步（复杂度极高） |
危险
异地多活不是「多机房各写各的库」那么简单：双向同步会带来冲突、回环与数据覆盖问题。没有成熟的冲突解决机制前，不要做真正的多活，优先做「异地灾备 + 一键切换」。
2. 备份异地留存（最低成本，必做）
bash
# 每天把备份同步到异地/对象存储
rsync -avz --bwlimit=20000 /data/backup/ backup@10.1.0.20:/data/backup_offsite/
# 或用对象存储工具
aws s3 sync /data/backup/ s3://my-bucket/mysql-backup/ --storage-class STANDARD_IA1
2
3
4
5
2
3
4
5
bash
# 定期校验异地备份可读（而不是只同步）
ls -lh /data/backup_offsite/ | tail -n 5
zcat /data/backup_offsite/logical/shopdb_latest.sql.gz | head -n 51
2
3
2
3
3. 跨机房只读副本（温备）
sql
-- 灾备机房建从库，异步复制
CHANGE MASTER TO MASTER_HOST='10.0.1.10', MASTER_USER='repl',
MASTER_PASSWORD='ReplPass!2026', MASTER_AUTO_POSITION=1;
START SLAVE;1
2
3
4
2
3
4
跨机房网络延迟高时，异步复制延迟会明显增大；这是 RPO 的主要来源。
4. 降低 RPO：半同步/延迟从库
sql
-- 半同步：至少一个从库收到日志才返回提交成功
INSTALL PLUGIN rpl_semi_sync_master SONAME 'semisync_master.so';
SET GLOBAL rpl_semi_sync_master_enabled = ON;
SET GLOBAL rpl_semi_sync_master_timeout = 1000; -- 超时后退化为异步1
2
3
4
2
3
4
sql
-- 延迟从库：故意落后 1 小时，用于误操作时快速取回数据
CHANGE MASTER TO MASTER_DELAY = 3600;
START SLAVE;1
2
3
2
3
5. 灾难切换预案（文档化 + 演练）
预案必须写明：触发条件、决策人、切换步骤（逐条命令）、验证清单、回退步骤。
bash
# 切换核心动作示例（灾备机房）
STOP SLAVE;
RESET SLAVE ALL; # 断开与故障主库的关系
SET GLOBAL read_only = OFF; # 开放写入
# 然后：变更应用连接 / 代理写节点 / DNS 或 VIP1
2
3
4
5
2
3
4
5
验证
- [ ] 异地备份可下载且能还原（每季度至少演练一次）
- [ ] 灾备从库延迟在可接受范围，且切换脚本执行过演练
- [ ] 预案中 RPO/RTO 与业务负责人确认过并留档
- [ ] 切换后应用连接、权限、备份任务均已指向新主
常见坑
WARNING
跨机房复制链路未加密会泄露数据；机房间用 TLS 或专线传输。
WARNING
灾备机房长期无人验证，真出事时才发现版本/参数/权限都不一致；建议定期做只读流量回放。
DANGER
切换后忘记在旧主上关闭写入就恢复服务，会形成「双写脑裂」，数据冲突后极难修复；恢复旧主前必须先确认其已成为从库且只读。