解读

在国内多云、混合云项目交付中，“网络分区”常被面试官具象化为“主可用区到 Google 骨干网中断，但主实例仍活着”。此时 Cloud SQL 的高可用（HA）实例虽然已启用跨区域（Regional）磁盘级同步，却因脑裂风险不会自动切换。面试官想看两点：

1. 你是否理解**“手动触发”与“自动 failover”**的边界；
2. 你是否能在国内网络合规（如跨境专线、BGP 路由黑洞）场景下，用最小 RTO 把业务切到备可用区，并保证数据零丢失。

知识点

• HA 架构：Regional 实例 = 主可用区主节点 + 异可用区备用节点 + 跨区域 Persistent Disk 同步。
• 故障检测信号：Google 内部健康检查走私有 VPC 通道，与国内云厂商的“多活”不同，不依赖客户侧探活。
• 手动 failover API：gcloud sql instances failover <实例ID> --project=<项目>，底层调用 instances.failover REST 接口，强制提升备用节点为 PRIMARY。
• RPO 保证：因同步复制，failover 点 LSN ≥ 原主最新提交 LSN，国内实测 RPO≈0。
• 网络分区特殊点：若原主因分区未宕机，API 会调用** fencing 机制通过底层分布式锁 STONITH** 原主，防止双写。
• 权限模型：国内客户常把运维账号收敛到自定义 IAM 角色，需提前授予 roles/cloudsql.editor 或至少 cloudsql.instances.failover 权限。
• 合规审计：国内金融客户要求操作留痕，命令后需追加 --format=json 并把回显写入操作票系统，满足等保 2.0 变更管理。

答案

步骤如下，全部在国内可访问的 Cloud Shell（北京/上海 POP 出口）完成，无需 VPN：

1. 确认实例类型为 HA
   gcloud sql instances describe <实例ID> --format="value(settings.availabilityType)"
   回显应为 REGIONAL，否则无法手动 failover。

2. 检查当前主可用区
   gcloud sql instances describe <实例ID> --format="value(gceZone)"
   记录返回值，例如 cn-northeast1-c，用于后续验证切换成功。

3. 触发手动故障转移
   gcloud sql instances failover <实例ID> --project=<项目> --async
   使用 --async 避免终端等待，适合国内弱网场景；命令返回的 operation id 可继续轮询。

4. 等待状态翻转
   gcloud sql operations wait <operation id> --timeout=300
   国内实测平均 55 秒完成，最长不超过 3 分钟；若超时需提工单到谷歌中国技术支持（Shanghai GTSC）。

5. 验证新主可用区
   重复第 2 步命令，若可用区已变动（如变成 cn-northeast1-b），且 databaseVersion 状态为 RUNNABLE，则手动 failover 成功。

6. 应用侧重连
   通知研发把读写流量指向原只读 IP（无需改连接串，因为 IP 随实例漂移），同时检查云监控中 cloudsql.googleapis.com/database/mysql/connections 指标是否回升。

拓展思考

• 脑裂二次保护：如果网络分区已恢复，原主节点短暂复活，可通过查询 mysql.gtid_executed 或 pg_control_checkpoint() 确认原主日志落后，避免业务双写。
• 自动化预案：在国内 Terraform 多环境流水线里，可把上述 3 个 gcloud 命令封装为本地-exec 资源，配合云监控告警策略（metric: cloudsql.googleapis.com/ha/health = false 持续 60 秒）实现半自动故障转移，既满足监管“人工确认”要求，又把 RTO 压到 2 分钟以内。