服务器容灾演练需主动验证故障接管、数据零丢失与业务不中断，核心是模拟真实故障、验证切换与回切全流程。应明确目标场景，如单机宕机迁移、数据库主从切换或跨机房流量接管；执行前须暂停主机映射、冻结应用写入、确认同步状态并备份配置；切换后需检查服务状态、arp更新及真实业务交易；务必完成回切、增量同步、流量渐进恢复，并更新问题整改清单。（149字符）
服务器容灾演练不是“等出事再试”，而是主动验证系统能否在故障时快速接管、数据不丢、业务不瘫。核心在于模拟真实故障、验证切换流程、确认回切能力，而不是走形式。
明确演练目标和场景
先想清楚这次练什么：是验证单台服务器宕机后的自动迁移？还是整套数据库主从切换？或是跨机房故障时的流量接管？常见有效场景包括：
- 主动中断主节点网络（如用 iptables -A INPUT -s [主库IP] -j DROP）
- 手动停止关键服务（如 systemctl stop postgresql 或 docker stop app-db）
- 模拟存储不可用（卸载或屏蔽共享存储LUN，或断开iSCSI会话）
- 人为清空DNS缓存或修改VIP绑定，测试负载均衡器故障转移逻辑
避免只做“桌面推演”——没动真实服务，就等于没练。
执行切换前必须做的准备
真正切换前，有几件事不做，演练就可能变成事故：
- 暂停生产主机映射：如使用SAN存储，需先在主机侧取消LUN映射，防止脑裂写入
- 冻结应用写入：停掉定时任务、关闭API入口（如Nginx return 503）、断开数据库写连接池
- 确认同步状态：检查主从延迟（MySQL Seconds_Behind_Master）、PostgreSQL复制位点、或备份时间戳是否满足RPO要求
- 备份当前配置快照：包括/etc/keepalived/、/etc/haproxy/、数据库pg_hba.conf等，便于回滚
切换与验证的关键动作
切换不是点个按钮就完事，每一步都要有确认项：
- 触发切换后，立即检查新节点服务进程是否运行、端口是否监听（ss -tlnp | grep :3306）
- 验证ARP缓存是否更新（arp -a | grep [VIP]），避免流量仍发往旧地址
- 用业务账号登录系统，执行一笔真实交易（如下单、查账、上传文件），不只看接口返回200，要看数据落库、日志生成、下游通知是否完整
- 比对关键表最新记录ID或时间戳，确认无数据跳变或丢失
务必完成回切和收尾
很多团队只做“切过去”，却忽略“切回来”。不回切，等于没闭环：
- 恢复原主节点后，先同步增量数据（如MySQL GTID补同步、PostgreSQL pg_rewind）
- 重新挂载存储、重建主机映射关系
- 逐步放开流量（如通过权重调整），观察监控指标（CPU、慢查询、错误率）是否回归常态
- 清理演练中创建的临时配置、测试数据、告警抑制规则
最后更新文档：把本次演练中暴露的问题（比如某脚本超时未退出、某中间件配置缺失健康检查）写进整改清单，明确责任人和时限。
