解读

在国内金融、电商等高并发场景下，Cloud SQL 实例偶尔会因 OOM、宿主机故障或用户误操作而需要重启。面试官想确认两点：

1. 你是否理解 Google 托管层 在两种重启路径中对 事务回滚（crash recovery） 的自动化差异；
2. 能否把差异翻译成 RTO、RPO、锁等待、连接风暴 这些业务可感知的指标，而不是背文档。
   答得越贴近国内“秒杀”“大促”真实痛点，得分越高。

知识点

1. 常规重启（soft restart）

   • 由用户控制台、gcloud 或维护窗口触发；Cloud SQL 先向数据库进程发 SIGTERM，允许 活跃事务优雅回滚，随后做一次 checkpoint；
   • 回滚阶段由 原实例 Pod 内的 buffer pool 完成，Double Write + Redo 顺序扫描量小，RTO 通常在秒级；
   • 重启后 binlog 位点连续，无需额外补数据，RPO=0；
   • 国内合规要求下，审计日志会记录“USER_RESTART”事件，便于等保核查。

2. 强制重启（hard restart / force restart）

   • 底层宿主机宕机、OOM Kill 或用户点击“强制重启”时，SIGKILL 直接杀进程，内存中的脏页与未提交事务全部丢失；
   • 实例拉起后，Cloud SQL 启动 crash recovery，并行回滚线程扫描 最后一个 checkpoint 到 crash 点之间的 redo log，回滚段重新构建；
   • 若实例规格大（如 64 vCPU/416 GB），回滚阶段可能持续 3～10 分钟，期间 连接被拒绝，业务侧出现“雪崩”；
   • 由于 binlog 可能不完整，若存在 跨区域只读实例，延迟复制线程会报错 1236，需要 重建只读实例，RPO 可能达到几十秒；
   • 国内双活架构中，强制重启后常触发 DTS/DRS 校验任务，增加 公网流量费用。

3. 关键差异一句话总结
   常规重启=“优雅回滚 + 秒级 RTO”；强制重启=“crash recovery + 分钟级 RTO + 可能补数据”。

答案

“在 Cloud SQL 中，常规重启会先发 SIGTERM，让未提交事务利用 buffer pool 就地回滚，并做一次 checkpoint，因此回滚阶段耗时短、RPO=0；而强制重启直接 SIGKILL，实例重启后必须进入 crash recovery，通过并行线程重放 redo 并回滚未提交事务，回滚耗时随脏页量线性增长，可达数分钟，且可能因 binlog 断裂导致只读实例重建，RPO>0。国内大促场景下，强制重启常引发连接池爆满与订单重复扣款，必须通过限流与幂等键兜底。”

拓展思考

1. 国内银行核心系统若使用 Cloud SQL + 两地三中心，建议把 maintenance window 设在凌晨 04:00–05:00，并 提前 24 h 通过云监控 MNS 告警通知业务；
2. 对 强制重启后的长回滚，可临时调大 cloudsql.max_parallel_workers 参数（需提工单白名单），并行度=CPU 核数/2 时回滚速度提升 40%；
3. 若业务侧无法容忍分钟级不可用，可在 ProxySQL 层配置 fast failover，把流量瞬间切到 跨区域只读实例，并 打开 gtid_mode=ON，确保 binlog 补完后自动回切，实现 RTO<30 s 的“伪双活”。