解读

面试官把“5 分钟业务恢复、1 分钟数据丢失”这两个硬指标抛出来，核心想验证三件事：

1. 你是否清楚 HA（区域级高可用）与跨区域只读/故障转移副本 在 RTO/RPO 上的能力边界；
2. 能否用 最少组件、最低成本 把两个指标同时兜住；
3. 对中国大陆网络合规、延迟、费用敏感点有没有体感。
   答“只开 HA”或“只开跨区域副本”都会直接 0 分，因为单独 HA 无法抵御区域级灾难，单独跨区域副本默认是只读，手动提升主库至少 5–10 min，RTO 直接超标。

知识点

1. HA（Regional HA）：在同区域双可用区部署主实例 + 故障转移实例，同步复制，Google 托管自动切换，RTO≈30–60 s，RPO≈0 s，但无法抗区域级故障。
2. 跨区域只读副本（Cross-region read replica）：异步复制，默认延迟 1–5 s，手动提升为主库时 RTO≈5–10 min，RPO≈复制延迟。
3. 级联复制拓扑：主 → HA 故障转移实例 → 跨区域副本，可让副本延迟稳定在 <1 s，满足 RPO=1 min。
4. 中国大陆合规：若主实例在 香港、东京、新加坡 任一区域，副本建议放在 另一个海外区域，避免跨境 ICP 备案复杂度；如果业务主体在国内且已拿备案，可选 北京/上海/深圳 作为主，香港 做副本，但需评估 30–40 ms 延迟对异步复制的影响。
5. 自动化脚本：用 Cloud SQL Admin API + Cloud Functions + Monitoring Alert 实现“检测到主区域不可用 → 一键 promote replica → 更新云解析或 Cloud Load Balancer 后端”，把手动 10 min 压到 <5 min。
6. 费用模型：HA 本身 + 跨区域副本出方向流量费（每 GiB 0.12–0.19 USD），面试时要主动提“成本预算”并给出 按量+承诺使用折扣（CUD） 组合方案，体现商业意识。

答案

“为同时满足 RTO=5 min、RPO=1 min，我会采用 HA + 跨区域只读副本 + 自动提升脚本 的三层方案：

1. 主实例开启 Regional HA，兜住单机/可用区故障，日常 RTO/RPO 接近 0；
2. 在 异地区域 创建 级联只读副本（主 → HA 故障转移 → 异地副本），通过 并行复制、调大 max_parallel_workers、开启 logical_decoding 把复制延迟压到 <1 s，从而把 RPO 锁在 1 min 以内；
3. 用 Terraform 固化 副本规格与 IP 白名单，部署 Cloud Monitoring 指标 alert（mysql.googleapis.com/replication/seconds_behind_master > 30 s 就告警），同时挂一个 Cloud Functions 脚本，监听 Cloud SQL 生成的 FAILURE 事件 或 MTR 丢包>50% 的 uptime check，一旦触发立即调用 instances.promoteReplica API，并同步修改 Cloud DNS A 记录 或 CLB 后端服务，把业务流量切到新主库；
4. 整套脚本实测 promote 耗时 110 s + DNS TTL 60 s + 应用重连池 30 s ≈ 3 min，加上 1 min 缓冲，总 RTO<5 min；
5. 最后每月做一次 GameDay：人为关闭主区域 VPC 路由，验证脚本真实耗时与数据零丢失，演练报告归档供审计。
   这样即可在 不违反中国跨境合规 的前提下，用 最小额外成本 把两个硬指标同时做到。”

拓展思考

1. 如果业务要求 RPO=0，上述方案就不够，需要 跨区域同步——但 Cloud SQL 原生不支持，此时要 主动降级：建议面试官改用 AlloyDB Omni +跨区域同步复制 或 Spanner，并给出 成本翻倍、延迟上升 的权衡，体现 技术选型的边界感。
2. 对 金融级两地三中心，可再叠加 同区域三节点 HA（即将推出）+ 异地只读副本 + 对象存储导出（Point-in-time recovery），形成 0-1-5-7（0 数据丢失、1 min 内发现、5 min 切换、7 天内可回溯）的国内监管模板。
3. 面试反向提问：可以问面试官“预算上限多少？是否接受只读业务短暂受损？”——把 非功能需求 拉回桌面，展示 架构师思维而非纯运维思维。