摘要
2026-03-10 15:57 UTC，Clerk 的认证 API 出现延迟与 5xx 飙升，数据库出现锁竞争。根因是上游 Google Cloud SQL 的一次实时迁移（live migration）使磁盘延迟骤增，引发锁竞争并最终导致服务中断；约 26 分钟后迁移完成、数据库自行恢复。
时间线
- 15:57 UTC :: 告警触发，API 延迟与 5xx 升高
- 16:10 UTC :: 启用 Origin Outage Mode 保会话，但计算资源已饱和仍返 429
- 16:23 UTC :: 实时迁移完成，数据库恢复，关闭 Outage Mode
根因
Google Cloud SQL 实时迁移在本例未如预期工作，磁盘延迟显著上升，引发数据库锁竞争；Clerk 的计算资源被查询耗尽，请求排队返回 429。
放大因素
会话令牌请求也因计算饱和大量返回 429；监控仅显示锁竞争但一时无明确根因，初期误判为自身问题。
缓解措施
已要求 Google 将数据库重新固定（pin）以避免后续实时迁移；期间启用 Origin Outage Mode 维持会话；推动降低单请求查询数、引入托管连接池。
经验教训
上游托管数据库的运维操作（如实时迁移）可在客户无感知下引发中断；应在 SLA 中明确此类供应商操作的告知与回滚机制；对锁竞争类故障需有独立的资源隔离兜底。
检查清单
- 梳理所有依赖「供应商透明运维操作」的关键路径
- 为数据库类依赖配置资源隔离与熔断兜底
- 与云厂商约定实时迁移的提前告知与固定机制
- 定期演练 Origin Outage Mode 等降级开关