从可用区故障看数据库高可用配置与五层验收方法
导语
2026 年 10 月 20 日伦敦当地时间，Google Cloud europe-west2-b 可用区因供电事件不可用，Cloud SQL、AlloyDB、Spanner 等服务被列入官方影响名单。多家银行服务受波及，欧洲金融监管机构已跟进。
但官方公告没有披露任何一家银行的数据库切换细节。我们不能因为 Cloud SQL 在名单里，就推断某家银行一定是数据库故障、备库切换失败或数据丢失。对工程团队更有价值的问题是：
- 自己的可用区挂了，数据库能不能切？
- 应用连接会不会跟着切？
- 故障窗口内已经确认写入的数据还在不在？
- 业务什么时候才算真正恢复？
下面不猜测具体银行，只把这次可用区故障当成一张检查题。文末给出一份可以直接用于演练记录的五层验收表。
一、故障触发条件：先看完整链路
数据库可用，不代表业务请求可用。现代分布式系统里，一次用户请求通常要经过这样一条链路：
text
用户请求
↓
流量入口（负载均衡 / API 网关）
↓
应用服务与网络
↓
连接池 / 服务发现
↓
数据库
↓
下游服务任意一个环节卡住，都可能导致业务不可用。常见的问题是：只盯数据库实例状态，忽略了应用连接池、服务发现、网络路由和下游依赖。
所以处理可用区故障时，不应该只问"数据库挂了没"，而要问：
- 流量入口是否还能正常分发？
- 应用是否还在向旧地址建立连接？
- 连接池是否缓存了大量失效连接？
- 数据库切换后，读写路由是否指向了新主？
- 下游服务是否因为超时或重试把上游拖垮？
这些检查项，后面会落在五层验收表里。
二、高可用配置差异：不能一把抓
Cloud SQL 的两种行为
根据 Google 官方文档，Cloud SQL 的高可用行为并不完全相同：
- 区域高可用配置：启用后，实例遇到故障时可以在另一个可用区自动恢复，并且继续使用同一 IP。
- 单可用区配置：实例遇到整区故障时不会自动恢复。后续怎么恢复，取决于备份、可用副本和事先准备好的恢复路径。
也就是说，同样叫"云数据库"，高可用等级可能差异很大。
其他云数据库不能直接套用
这次受影响名单里还有 AlloyDB 和 Spanner，但不能把 Cloud SQL 的切换行为直接套到它们身上，更不能据此推断受影响银行用了哪种数据库。
真正要检查的是自己系统的实际产品、版本和配置。尤其要确认：
- 是否启用了跨可用区高可用？
- 故障切换是自动还是人工？
- 切换后 IP 是否变化？
- 应用连接串、服务发现、连接池是否支持这种变化？
- 单可用区部署时，恢复路径是什么？
如果你用的是单可用区 Cloud SQL，遇到整区故障不会自动恢复。这时你的 RTO 取决于你提前准备了多少：备份、跨区副本、手工升主流程、应用改连方案。
三、五层验收方法
为了判断"数据库恢复"是否真的等于"业务恢复"，建议按五层验收。每一层都要有明确的观察指标和通过依据，不能只看实例状态。
1. 入口 / 应用层
为什么查： 用户请求能不能进来，能不能返回成功。
- 观察指标：关键请求成功率、响应时间、错误率
- 通过依据：关键请求恢复，失败率与延迟回到业务事先约定的阈值。阈值应来自业务 SLO，而不是统一写成某个固定百分比。
2. 连接层
为什么查： 数据库切了，应用可能还连在旧地址上。端口通、进程在，不代表连接可用。
- 观察指标：连接池状态、连接成功率、连接超时率、目标地址
- 通过依据：旧连接被正确回收或重试，新连接到达当前主节点，写请求不再落到旧地址。
这里还要补充一点：故障检测不能只看端口通不通。需要结合业务失败率、真实读写探测、I/O 与复制指标。否则很容易出现"数据库进程在，但业务已经失败"的误判。
3. 主备角色切换
为什么查： 没有唯一主库，就有双主和写入分叉风险。
- 观察指标：主库状态、备库状态、切换时间
- 通过依据：新主身份唯一，旧主停止接受写入；切换时间计入端到端 RTO，而不是单独充当 RTO。
对于需要人工升主或回切的架构，必须确认旧主已经隔离，不再接受写入。否则可能出现两边同时写，数据分叉。
4. 数据层
为什么查： 实例在线了，不代表故障窗口内的数据都在。
- 观察指标：数据一致性、复制延迟、数据完整性、差异清单
- 通过依据：核对故障窗口内已确认的业务写入，测出实际 RPO，并记录需要补偿或对账的差异。
异步主备可能有复制延迟；即使是宣称同步保护的方案，也要核对故障窗口内业务已经确认写入的数据是否真的落到了备用节点。
5. 业务层
为什么查： 恢复完成要看用户业务与数据对账，不只看实例在线。
- 观察指标：关键业务路径成功率、业务数据对账
- 通过依据：从入口完成约定的查询和可回滚写入；关键业务恢复时间符合事先约定的 RTO。
文本流程图
text
用户请求
↓ 检查入口与应用：关键请求是否还能进入、是否成功？
连接池 / 服务发现
↓ 检查新连接：是否连到当前主节点？
数据库主备角色
↓ 检查旧主：是否已经停止接受写入？
已确认写入与复制状态
↓ 检查 RPO：故障窗口内的业务数据是否完整？
用户关键路径
检查 RTO：从故障发生到查询和写入恢复用了多久？精简验收表
| 层次 | 观察指标 | 通过依据 |
|---|---|---|
| 入口/应用 | 关键请求成功率、延迟 | 回到该业务预先约定的阈值 |
| 连接 | 连接错误、重试、目标地址 | 应用重连到当前主节点 |
| 主备角色 | 节点角色、写入入口 | 新主唯一，旧主不再接受写入 |
| 数据 | 已确认写入、复制状态、差异清单 | 测得实际 RPO，差异可解释和处理 |
| 业务 | 查询与可回滚写入、恢复用时 | 关键路径跑通，测得实际 RTO |
四、两个案例的对照
案例一：OA 系统磁盘 IO 异常
我们社区分享过一份 OA 系统故障记录：一主一从环境里，数据库进程出现 I/O 堵塞，随后数据库异常，业务不可用。现场核查日志和监控后，仍没有足够证据锁定底层根因，磁盘损坏、文件系统挂起等只是可能的诱因。
这个案例不能用来解释伦敦供电事件，但它提醒我们：只盯"进程在不在"，可能漏掉 I/O 堵塞到业务失败的整条时间线。故障检测需要把业务失败率、真实读写探测、I/O 与复制指标一起纳入。
案例二：同城双中心网络中断恢复预案
我们在一个同城双中心项目中编制过一份《同城双中心网络中断 KES 集群切换及 KFS 链路恢复指南》。预案假设两地网络断开后，灾备节点升为主库，应用改连本地数据库；网络恢复后处理旧主、恢复同步链路，并核对断网期间的数据。
这份预案是纸面步骤，不是演练成绩单，也没有被这次伦敦事件验证。它更接近一次"恢复路径设计"：如果人工升主，旧主没隔离怎么办？如果网络恢复后发现两边都写过数据，该以哪边为准？这些问题只有通过接近生产的测试环境或受控演练才能回答。
五、演练记录模板
演练不必从一份长报告开始，先把下面几项填清楚。故障可以在接近真实部署的测试环境，或经过批准的受控场景中模拟；如果环境与生产不同，要记录差异，不要把测试结果直接当成生产承诺。
| 记录项 | 该留下什么 |
|---|---|
| 故障注入 | 失效的是哪个可用区、节点或网络链路；开始时间和触发方式 |
| 告警与决策 | 第一条业务告警何时出现，谁决定切换，依据哪些指标 |
| 主备与连接 | 新主何时开始接写入；旧主何时停止写入；应用何时重新连接 |
| 业务验收 | 哪些查询和可回滚写入从用户入口跑通，最后成功时间是什么 |
| 数据验收 | 故障窗口内已确认写入的核对结果、差异清单和实际 RPO |
| 恢复收尾 | 旧主处理、复制链路恢复、数据对账及是否需要回切 |
这张表可以分别量出"数据库升主用了多久"和"业务真正恢复用了多久"，也能保留事后解释 RPO/RTO 的证据。
回切不是演练的自动收尾动作。应先确认旧主状态与数据一致性，再按预案决定是否执行。旧主未隔离且仍接受写入时，双主和分叉风险会一直存在。
六、结语
伦敦事件没有给出银行各自的数据库故障链，我们也不该替它补一条。它留给工程团队的检查题更直接：
- 你的系统何时能发现故障？
- 哪一层负责切换？
- 应用多久能重新工作？
- 故障窗口内的数据怎么对账？
把这几项跑通并留下记录，才知道"高可用"在自己的业务里兑现到了哪一步。