1.
概述与应急前提
在确认 Vultr
日本机房不可用后，首先判断影响范围（应用、数据库、CDN、静态文件、邮件等）。优先级：保证业务最关键的写库和用户请求线上通畅。切换前需确认备用机房（例如新加坡/美国）的资源已预配、网络连通、备份数据最新。
2.
事前准备（应急 runbook）
提前准备好：降低 DNS TTL（建议 60s）、备用机房账号/API 凭据、浮动 IP 或 BGP 配置权限、数据库从库/备库的最近复制位置、rsync/对象存储跨区复制脚本、自动化脚本存放在版本库并能远程执行。
3.
检查并同步数据（文件与对象）
静态文件：用 rsync 或 rclone 同步最新文件，例如：rsync -az --delete /var/www/ backup@bk:/var/www/。对象存储：确保 S3 或兼容对象有跨区复制（CRR）或手动 sync。不要跳过校验：对比文件数量、大小和 md5。
4.
数据库切换操作（MySQL/Postgres/Redis）
MySQL：在备用机房将从库提升为主：STOP SLAVE; RESET SLAVE ALL; SET GLOBAL read_only=OFF; 修改应用 DB 配置指向新主。Postgres：在流复制从库执行 pg_ctl promote 或 create trigger file；更新连接串。Redis：若为主从，执行 redis-cli -h
SLAVEOF NO ONE。
5.
IP 与路由切换（Floating IP / BGP / 负载均衡）
如使用浮动 IP（Vultr/其他云均有），通过控制台或 API 将浮动 IP 指向备用机房实例。若使用 Anycast/BGP，请协调网络团队宣告新线路。若前端使用云负载均衡，切换后端目标组到备用机房实例。
6.
DNS 切换实操
当 TTL 已提前降低到 60s，实时切换步骤：通过 DNS 提供商 API 批量更新 A/AAAA 记录或 CNAME 指向备用机房。示例（伪）curl：curl -X PUT "https://dns.api/zone/record" -H "Authorization: Bearer TOKEN" -d '{"type":"A","name":"www","content":"备用IP"}'。切换后监控 DNS 解析生效（dig +short www.example.com）。
7.
CDN 与缓存策略
如果使用 CDN（如 Cloudflare），在控制台切换后端或开启“暂用模式”保持缓存服务在线。清理必要缓存：对动态页面做短期缓存策略，避免瞬时流量打到新主造成压力。
8.
服务切换后的验证步骤
切换后立即做烟雾测试：访问首页、API 登录、数据库写入读出、队列入队出队等。使用 curl、Postman 或自动化脚本验证各关键接口（状态码、响应时间、业务数据正确性）。确认日志无大量错误后逐步放量。
9.
监控与回滚准备
监控包含：应用错误率、响应时间、数据库延迟、磁盘 I/O、带宽。若出现严重问题按回滚计划执行：1) 将 DNS 指回原机房（在 TTL 短的情况下可快速生效）；2) 将新写入数据同步回原主并按顺序切换写方向；3) 通知用户并记录事件。
10.
自动化与演练建议
把切换流程脚本化（Terraform/Ansible/Shell），并定期演练（桌面演练+实战演练）。每次演练记录时间、失败点并完善 runbook。提前准备通信模板（对内/对外）和责任人名单。
11.
问：切换时怎样最小化数据丢失风险？
答：确保有实时或准实时的数据库复制（主从/多主）并在切换前确认从库落后位点小于可接受窗口；用 rsync + 增量 binlog/gtid 回放同步写入；切换期间短暂关闭非核心写入或将写入队列暂存。
12.
问：DNS 切换生效慢怎么办？
问：DNS 切换生效慢怎么办？答：如果未提前降 TTL，老解析缓存会延迟生效。可同时使用浮动 IP、Anycast 或 CDN 层做流量引导，必要时联系 DNS 服务商请求加速变更或采用临时子域名绕开旧解析。
13.
问：如何验证切换后用户影响最小？
答：在切换后用真实用户路径和合成监控（Synthetics）检查关键业务（登录、下单、支付、查询）是否成功；逐步放量（灰度）流量；观察错误率和延迟，关闭有问题的功能点并回滚或修复。
来源：当 vultr日本机房死了 企业如何快速切换到备用机房策略
