解读

在国内金融、政企类项目中，VIP 租户往往要求 可审计、可回滚、长周期 的数据保护策略。Google Cloud SQL 默认的 PITR（Point-in-Time Recovery）保留期 与实例版本、存储容量、备份窗口及 transaction log（事务日志）留存策略 直接相关。面试官想考察的是：

1. 你是否理解 Cloud SQL 备份链路与日志留存机制；
2. 能否在 不中断业务 的前提下，为特定租户定制 差异化 SLA；
3. 是否熟悉 Terraform / gcloud / REST API 的灰度发布与权限收口做法，以满足国内合规“变更必审批、操作必审计”的要求。

知识点

1. PITR 上限：MySQL 5.7/8.0 与 PostgreSQL 13/14 均支持最长 35 天；SQL Server 因采用完整+差异+事务日志链，理论可支持 35 天但受 300 GB 日志上限硬限制。
2. 日志留存三要素：
   • backupRetentionSettings.retentionUnit = COUNT，retentionCount 最大 365（仅影响自动备份，不影响 PITR）；
   • transactionLogRetentionDays 参数（仅 PostgreSQL 与 SQL Server 支持，MySQL 需依赖二进制日志留存时间）；
   • disk autogrowth 必须开启，否则长周期日志可能打满磁盘触发 实例锁库。
3. 租户隔离方案：
   • 项目级隔离：为 VIP 租户单独开 Google Cloud Project，利用 Organization Policy 禁止其实例缩短保留期；
   • 实例级标签：通过 labels={"tenant":"vip"} 与 IAM Conditions 绑定自定义角色 roles/cloudsql.vipAdmin，仅允许 DBA 修改 retention；
   • Terraform 模块：在 CI/CD 流水线 中强制校验 transaction_log_retention_days ≥ 35，否则 build 失败。
4. 合规审计：启用 Cloud Audit Logs 的 data_access 类型，把 cloudsql.instances.patch 事件实时推送到 BigQuery + 日志接收器，对接 国内 SOC/等保 3.0 审计系统。
5. 成本风控：长周期日志会 线性增加存储计费；需为 VIP 租户单独创建 Budget Alert，阈值 80% 时触发 Pub/Sub 通知企业微信/飞书群，避免 月底账单暴击。

答案

步骤如下，全部通过 gcloud 完成，可无缝嵌入 国内金融云自动化平台：

1. 确认实例引擎与版本：
   gcloud sql instances describe <vip-instance> --format="value(databaseVersion)"
   若返回 MYSQL_8_0，需额外调大 binlog_expire_logs_seconds（默认 604800 s，即 7 天）；PostgreSQL 或 SQL Server 跳过此步。
2. 开启磁盘自动扩容并设定上限（防止日志打满）：
   gcloud sql instances patch <vip-instance> --storage-auto-increase --storage-auto-increase-limit=XXGB
3. 修改事务日志保留期（以 PostgreSQL 为例）：
   gcloud sql instances patch <vip-instance> --transaction-log-retention-days=35
   MySQL 需先通过 flags 设置 binlog_expire_logs_seconds=3024000（35 天），再执行 patch。
4. 强制备份窗口与保留次数（满足等保“至少保留 12 次全备”）：
   gcloud sql instances patch <vip-instance> --backup-start-time=02:00 --backup-retention-count=12 --retention-unit=COUNT
5. 标签与 IAM 收口：
   gcloud sql instances patch <vip-instance> --update-labels=tenant=vip,env=prod
   绑定自定义角色：
   gcloud iam roles create vipSqlRetention --project=<project> --permissions=cloudsql.instances.update,cloudsql.instances.get
   并通过 IAM Conditions 限定仅当 resource.labels["tenant"]=="vip" 时可修改 retention。
6. 审计与告警：
   在 Cloud Logging 创建接收器：
   gcloud logging sinks create vip_sql_audit bigquery.googleapis.com/projects/<project>/datasets/audit --log-filter='protoPayload.methodName="cloudsql.instances.patch" AND resource.labels.database_id="<project>:<vip-instance>"'
   同时创建 Budget 与 Alert，阈值 80% 推送至 飞书群。

完成以上 6 步，即可在 零停机 情况下为 VIP 租户提供 35 天 PITR 能力，并满足国内 等保、审计、成本 三重合规要求。

拓展思考

1. 若 VIP 租户要求 跨地域长周期 PITR（如 90 天），Cloud SQL 原生上限不足，可设计 “日志转储 + 自建回放” 方案：
   • 使用 Pub/Sub + Dataflow 实时导出 WAL/Binlog 到 Cloud Storage 冷线存储；
   • 通过 Terraform 编排 GKE 作业，按需回放至 临时实例 实现 任意时间点恢复；
   • 成本可下降 60%，但需自行处理 GTID 一致性 与 跨地域带宽费用。
2. 国内 双录（录音录像）业务 要求 不可篡改：可结合 Cloud SQL CMEK（客户管理的加密密钥） 与 Bucket Lock，把 事务日志 作为 法律证据链 封存，满足 银保监 2023 年 3 号令。
3. 未来 Cloud SQL 若推出 “日志池化” 功能（类似 Aurora Backtrack），可进一步把 PITR 窗口 扩展到 365 天；作为架构师，应提前在 Terraform 变量层 预留 retention_days 字段为 number 类型，避免 硬编码 35 导致后续 全网变更。

掌握以上思路，你不仅能在面试中 精准回答 PITR 配置细节，还能展示 对国内合规、成本、未来演进 的 端到端设计能力，轻松拿到 Google Cloud SQL 专家岗位 的 Pass 卡。