解读

在国内金融、电商、政务云等真实场景中，数据校验和（Data Checksum）失败往往意味着磁盘静默损坏、网络位翻转、备份文件被篡改或主从副本之间出现逻辑不一致。Google Cloud SQL 虽然全托管，但租户侧仍需在RPO/RSLA约束下快速止血，否则可能触发监管罚单（如银保监会《商业银行数据中心监管指引》要求 2 小时内恢复）。面试官想考察：

1. 能否在共享责任模型下区分平台侧与租户侧职责；
2. 能否用最小权限+可回滚手段优先恢复业务，再定位根因；
3. 能否把 Google 原生工具（Cloud SQL Admin API、Cloud Logging、Cloud Monitoring）与国内常用的应急指挥、两级变更、红蓝军机制结合起来。

知识点

1. 共享责任模型：Google 负责物理磁盘、宿主机、文件系统校验和，租户负责逻辑一致性、SQL 注入、应用侧位翻转。
2. Cloud SQL 内置校验和：InnoDB 的 innodb_checksum_algorithm=crc32 或 PostgreSQL 的 data_checksums=on，每秒后台线程扫描，失败即抛 “checksum mismatch page xxx” 到 Cloud Logging。
3. 国内合规“先报告、后操作”：金融类系统需5 分钟内向信息科技部门口头报告，30 分钟内书面报告，并留存审计日志。
4. 三级应急预案：
   • P1：数据页级损坏 → 优先故障转移到 HA 备库；
   • P2：备库亦损坏 → 用最近一致性备份+PITR；
   • P3：备份亦污染 → 走跨地域长期存储（Archive）+ 谷歌工单升级。
5. 最小权限回滚：通过Cloud SQL IAM 细粒度角色（roles/cloudsql.editor 仅允许 failover，禁止 delete）防止“一键删库”。
6. 国内网络特殊性：使用Cloud SQL Auth Proxy 的 unix socket + VPC Service Controls 防止因跨省公网抖动导致二次损坏。

答案

当 Cloud SQL 实例出现 “data checksum failure” 告警时，按以下七步应急流程执行，全程在企业微信应急群留痕，满足国内监管**“双人双岗、操作复核”**要求：

1. 0-1 分钟：告警分级与通报
   监控值班收到 Cloud Monitoring 的 database/checksum_failure 告警后，立即在ITSM 系统创建 P1 工单，@应用负责人、DBA 值班、安全合规岗，同步口头上报科技风险部。

2. 1-3 分钟：快速健康度检查
   用 gcloud sql instances describe <INSTANCE_ID> --project=<PROJECT> 查看 currentDiskBytes / settings.tier / failoverState；若 availabilityType=REGIONAL 且 failoverState 为 NOT_FAILING，立即执行
   gcloud sql instances failover <INSTANCE_ID> --project=<PROJECT>
   该命令为在线提升，RTO 官方值 30-60 秒，国内实测北京区域约 45 秒，业务仅闪断一次 JDBC 连接池。

3. 3-5 分钟：一致性验证
   failover 完成后，用只读账号在 HA 备库执行 pt-table-checksum（MySQL）或 pg_checksums --check（PostgreSQL）抽样 5% 表，确认无新增 checksum error；若抽样通过，则降级告警为 P2，允许业务逐步放流量（灰度 10%→50%→100%）。

4. 5-15 分钟：根因定位与止血
   在 Cloud Logging 过滤
   resource.type="cloudsql_database" severity=ERROR "checksum mismatch"
   下载原始 JSON，提取 page_no、tablespace_id、LSN；若错误集中在一个 tablespace_id=5 的 .ibd 文件，判断为单表物理损坏，则：
   a. 用 REPAIR TABLE <tbl> USE_FRM; 尝试逻辑修复；
   b. 若修复失败，则隔离该表，应用侧降级为“无该表查询”模式，防止交叉污染。

5. 15-30 分钟：数据补全
   若表修复后仍丢失 2000 行以内，采用谷歌 DML 回放缓存（Cloud SQL 默认保留 7 天 binlog）在临时实例重放；若超过 2000 行，则按库维度从跨地域备份（北京→上海）做 PITR 到新实例，再用 gcloud sql instances promote-replica 切换 VIP。
   全程使用Terraform 变量开关 var.force_switchover=true 保证基础设施即代码可审计。

6. 30-60 分钟：监管报告与复盘
   填写《重大事件报告单》，含故障起始时间、影响交易笔数、实际 RPO、客户投诉量，加盖科技部门公章后 PDF 回传银保监会报备系统；
   24 小时内召开红蓝军复盘会，输出 5W2H 改进项，例如：

   • 将 data_checksums=on 纳入新实例 Terraform 模板强制项；
   • 把跨区域备份保留期从 30 天调到 90 天，满足《银行业信息系统灾难恢复规范》三级标准。

7. 后续加固
   启用 Cloud SQL Insights 持续 7×24 小时页面校验；
   通过 VPC Service Controls 设置北京-上海双地域隔离区，防止因运维误操作把上海备份也删除；
   每季度做一次** checksum 失败沙盘演练**，确保值班同学能在 5 分钟内完成 failover 操作。

拓展思考

1. 如果 checksum 失败发生在只读副本而非主库，国内电商大促期间是否敢直接删除副本？如何确保删除动作符合变更评审委员会的“三级审批”？
2. B 级机房电力闪断导致批量磁盘静默损坏，主备库同时出现 checksum 错误，而谷歌北京 region 当日备份窗口尚未完成，你会如何临时搭建一条从青岛 OSS 冷备到 Cloud SQL 的应急通道，满足银监会 2 小时恢复要求？
3. 国产数据库替代背景下，如果客户要求未来把 Cloud SQL MySQL 迁移至某国产集中式数据库，如何设计双轨并行校验方案，让业务层实时比对两国数据库的 checksum，确保字节级一致？