解读

在国内多租户 SaaS 场景里，“一个租户一个数据库” 既能满足数据隔离合规（等保、个人信息保护法），又方便后续按租户计费与迁移。但 Cloud SQL 是实例级服务，一个实例可建多个数据库，却共享备份窗口与保留策略。因此，面试官真正想考察的是：

1. 如何在实例数量、成本与隔离性之间做权衡；
2. 怎样把分散在各实例/库里的备份收口到一条 SLA 统一、可审计、可演练的策略；
3. 如何兼顾跨区域容灾与细粒度恢复。

知识点

• Cloud SQL 实例模型：MySQL/PostgreSQL 一个实例可建 N 个 database；SQL Server 一个实例默认一个系统库，用户库可多个，但备份仍以实例为单位。
• 备份类型：自动备份（每日窗口、7~35 天保留）、按需备份（手动、最长 365 天保留）、物理快照（基于底层分布式存储，非导出）。
• PITR：依赖自动备份 + WAL 实时归档，最小恢复粒度为实例级，无法单库回滚。
• IAM 与组织策略：通过标签+资源层次（组织→文件夹→项目）统一绑定备份保管规则；用组织策略约束“禁止关闭自动备份”。
• 跨项目与跨地域：使用Cloud SQL 跨地域只读实例做热备，Storage Transfer Service 把备份文件转存到另一个项目 + 冷存 Bucket，实现**“3-2-1”合规**。
• Terraform 模板化：用 for_each 批量生产实例，统一 backup_configuration 块，禁止本地差异。
• Cloud Composer / Workflows：编排每日“备份完整性校验 + 异地复制 + 发送审计报告”。
• 费用优化：共享 CPU 实例（最多 100 库） vs 专属实例（单库） 的 TCO 计算；合理设置保留天数避免快照堆积。

答案

给面试官一个可落地的三级方案，先讲思路再落地：

1. 租户分层

   • VIP/大客户：独占一个 Cloud SQL 实例，实例名即租户编码，方便后续整实例迁移。
   • 普通租户：10~50 个租户共享一个实例，每个租户一个独立 database，用Cloud SQL User 做库级鉴权，REVOKE跨库访问实现逻辑隔离。
   • 沙箱/试用：共用一个“sandbox”实例，database 名加前缀，定期 DROP 并重建，降低 idle 成本。

2. 统一备份策略
   a. 组织级约束

   • 在Google Cloud 组织策略里设置 sql.restrictPublicIp 和 sql.requireBackup 为强制，任何人无法关闭自动备份。
     b. 备份参数模板
   • 用 Terraform 模块固化：
     backup_configuration { enabled=true, start_time="02:00", location="asia-northeast1", point_in_time_recovery_enabled=true, transaction_log_retention_days=7, backup_retention_settings { retained_backups=30 } }
   • 所有实例通过 CI 流水线强制套用该模块，MR 阶段校验，差异即拒绝合并。
     c. 异地冗余
   • 每日自动备份完成后，Cloud Storage 事件触发 Workflows，把 mysql-binlog 与 auto-backup 文件复制到国内另一区域冷存 Bucket（例如北京→上海），保留 90 天。
   • 每月 1 号用Cloud Composer DAG 随机挑 1 个备份做恢复演练，启动临时实例并跑 mysqlcheck，结果写入Cloud Monitoring 自定义指标，SLA 不达标立即告警。
     d. 租户级恢复
   • 虽然回滚粒度是实例，但恢复后可用 mysqldump --databases tenant_xxx | gzip > tenant_xxx_$(date).sql.gz 导出单库，再导入到原实例新库，实现**“逻辑级 PITR”**，满足租户误删单表场景。

3. 治理与审计

   • Cloud Asset Inventory 导出所有 SQL 实例的 backupConfiguration 快照，BigQuery 做每日对比，发现“backup_enabled=false”立即自动修复并开 Jira 工单。
   • 备份费用按**“实例大小 × 保留天数 × 0.08 元/GB/月”** 估算，FinOps 看板每周推送给财务，超预算自动降保留天数或转冷存。

一句话总结：“用组织策略锁死底线，用 Terraform 模板消灭差异，用 Workflows+Composer 让备份可验证、可审计、可演练。”

拓展思考

• 如果租户增长到 5000+，实例爆炸怎么办？可引入 Cloud SQL Proxy + 中间层分片（ShardingSphere），把“单实例多库”升级为“单实例多库 + 水平分片”，备份策略仍复用同一套 Terraform 模板，逻辑租户与物理实例解耦。
• 国内金融客户要求**“备份数据不出境”，可结合Cloud SQL 北京/上海双区域** + Dedicated Interconnect 实现**“异地双活但不出国”，同时用KMS 国内密钥加密备份，满足银保监 39 号文**。
• 未来升级到 AlloyDB for PostgreSQL 时，其连续备份与子集群级恢复能力可把“租户级 PITR”从逻辑导出升级为秒级子集群回滚，TCO 再降 30%，可提前在架构白皮书中预留迁移钩子。