凌晨两点收到告警短信，网站打不开了。你登录服务器一看，数据库进程挂了，重启三次都起不来。这时候最该做的事情不是排查根因，而是先把业务切到备用服务器上恢复访问。根因可以慢慢查，用户不能等。
切换前的判断
先花30秒确认宕机范围。是单台应用服务器挂了，还是数据库挂了，还是整个机房都挂了？判断标准很简单：SSH能不能连上、Web服务进程在不在、数据库能不能连。快速定位到故障层，才能决定切什么。
如果只是应用服务器挂了，数据库还活着，那只要把流量切到备用应用服务器就行。如果数据库也挂了，就得连备用数据库一起切。
三种切换方式
DNS切换是最常用的。把域名的A记录从主服务器IP改到备用服务器IP，TTL设短一点（比如60秒），等DNS缓存刷新就生效了。缺点是生效时间取决于各级DNS缓存，快的话一两分钟，慢的话可能十几分钟。所以平时DNS的TTL别设太长，3600秒就够了，出事的时候临时改短。
负载均衡摘节点更快。如果你前面挂了SLB或者Nginx，直接把故障节点从upstream里摘掉，流量自动转到健康节点，几乎是秒级生效。这就是为什么建议生产环境前面一定要有负载均衡器，哪怕只有两台后端服务器。
全局DNS（如Cloudflare）切换适合整个机房挂了的情况。在CDN或智能DNS层面把流量指向备用机房，比改权威DNS生效更快，因为CDN的边缘缓存刷新比较及时。
切换后必须做的三件事
第一件：检查数据一致性。主备之间如果有复制延迟，切过去之后可能丢了一些写操作。对比一下主备的binlog位点或者最新的数据时间戳，评估丢了多少数据。
第二件：通知相关方。运维团队、业务负责人、客服都要知道发生了切换，客服那边好准备话术应对用户咨询。
第三件：监控新节点。切过去之后盯着CPU、内存、连接数、响应时间，确认备用服务器扛得住流量。别主服务器切过去了，备用服务器又被打爆了。
等主服务器恢复之后，先把增量数据同步回去，再选择业务低谷期做回切。回切不是必须的，如果备用服务器配置够用，直接把它当主服务器也行。
真正靠谱的故障转移，不是出事的时候临场发挥，而是平时就练过。建议每季度做一次切换演练，把流程跑顺，数据迁移备份和容灾切换的肌肉记忆比文档管用得多。