解读

国内面试官问这句话，表面看是“会不会断”，实质想确认三点：

1. 你对 Cloud SQL 实例架构层（主从、连接代理、GKE 托管控制面） 的理解深度；
2. 你是否清楚 MySQL 5.7 自身在线扩容的局限；
3. 你能否把“官方文档说可以无中断”翻译成“业务真实可观测的 RT 抖动与重连逻辑”。
   答“会”或“不会”都片面，必须给出 触发条件、观测指标、兜底方案 才算闭环。

知识点

1. Cloud SQL 热升级路径：修改 tier → 下发 rolling update → 先起高规格影子节点 → 通过内部健康检查 → 切换 VIP（或 Proxy 长连接）→ 释放旧节点。
2. MySQL 5.7 线程模型：one-thread-per-connection，改 vCPU 仅影响新连接调度，已有连接 FD 不变；但切换瞬间 VIP 漂移会导致 TCP 四元组变化，长连接会收到 RST。
3. 闪断判定标准：国内金融客户通常以 >200 ms 无响应或 error 1040/2013 记一次“业务闪断”。
4. Cloud SQL Auth Proxy 行为：默认 1 min 心跳，VIP 漂移后旧 TCP 隧道 60 s 后才感知，应用层先报“gone away”。
5. 降低中断手段：
   • 开启 Private IP + 连接池（Hikari/DBCP） 并设置 testOnBorrow=true；
   • 升级前把 wait_timeout 调到 60 s 以内，强制短连接；
   • 使用 Cloud SQL 高可用（HA） 时，先手动故障转移到备节点，再改主节点规格，可把中断压缩到 <3 s；
   • 对 MySQL 5.7 只读分析实例 先升配，再 promote 为 primary，实现 0 中断滚动。

答案

在 MySQL 5.7 单可用区实例 上执行 vCPU 热升级，默认会出现 2~15 秒的 TCP 层闪断；表现为：

• 已建立的长连接收到 RST 包，应用抛 “Communications link failure”；
• 连接池需 30 s~1 min 完成重试并恢复。
  若实例开启 HA（高可用） 并配合 Proxy+连接池重试策略，可把中断控制在 秒级甚至亚秒级，但严格意义上仍存在 毫秒级抖动，无法做到 0 包丢失。
  因此，对 SLA>99.99% 的核心支付链路，建议采用“蓝绿实例升降级”或“只读实例 promote”方案，而非直接热升级。

拓展思考

1. 如果业务已升级到 MySQL 8.0 on Cloud SQL，Google 引入 thread pool+connection multiplexing，热升级时影子节点可 pre-warm 连接状态，官方指标 P99 中断<1 s；可反问面试官“是否考虑引擎大版本升级”来体现前瞻性。
2. 国内 双活架构 下，可结合 Cloud SQL 跨区域只读副本 + DTS 双向同步，在升配前把流量切到对端 Region，实现 0 中断灰度，再把经验抽象成 Terraform 模块，用 Infrastructure as Code 固化流程，可进一步展示 SRE 自动化能力。