解读

在国内云厂商面试中，这道题考察的是候选人是否真正理解全托管数据库的备份与恢复机制，尤其是“能恢复到哪一秒”这一企业级核心能力。面试官希望听到：

1. PITR 的技术原理（基于连续日志 + 全量备份）；
2. 日志保留期如何直接决定可恢复的时间窗口；
3. 如果保留期设置不当，会带来合规风险与成本隐患。
   回答时务必把“日志链断裂”“RPO 违约”这些关键词抛出来，体现对生产故障场景的体感。

知识点

1. PITR 本质：利用全量备份 + 连续事务日志（MySQL binlog / PostgreSQL WAL / SQL Server log backup）把实例恢复到任意一秒的状态。
2. 事务日志保留期：Cloud SQL 在后台把日志自动上传至 Cloud Storage并保留的时长，默认 7 天，最高可配 35 天；超过保留期则日志被物理删除，日志链断裂。
3. 关系公式：可恢复最早时间点 = 最近全量备份时间 ≤ t ≤ 日志保留期截止时间；一旦日志被清理，早于该时间点的 PITR 直接失败，只能退回到“最近全备”做快照恢复，RPO 从秒级退化到天级。
4. 国内合规：等保 2.0 与《金融行业数据安全指引》要求关键业务 RPO ≤ 15 分钟；若保留期过短，审计现场会被出具不符合项。
5. 成本权衡：日志保留期每增加 1 天，Cloud Storage 容量费用线性上升；在华北-北京、上海-华东等国内多可用区部署时，跨区网络出流量费也会同步增加。
6. 运维陷阱：
   • 手动删除全备会导致日志链强制截断，即使仍在保留期内也无法 PITR；
   • 实例版本大版本升级后，旧日志不可复用，必须重新设置保留期并触发一次全量基线备份。

答案

点时间恢复（PITR）依赖连续的事务日志链，而事务日志保留期就是这条链的生命周期。
简单讲：保留期决定了你能“回到过去”多远。
在 Cloud SQL 中，系统每天自动做一次全量快照，并把后续产生的binlog/WAL实时上传至 Cloud Storage；只要日志在保留期内，就可以用全备 + 日志重放把实例恢复到秒级任意时间点。
一旦日志超过保留期被清理，日志链断裂，早于该时刻的 PITR 将直接报错，只能退回到最近全量快照，RPO 从秒级变成天级。
因此，保留期是 PITR 的时间窗口上限，也是企业 RPO 合规的硬门槛；在国内金融、政企场景，通常把保留期调到30 天以满足监管对“可回溯、可举证”的要求，同时通过生命周期策略把 7 天后的日志转入Nearline/Archive层，平衡成本。

拓展思考

1. 如果业务要求45 天 PITR，但 Cloud SQL 上限只有 35 天，如何设计？
   答案：使用自建导出 + 日志归档混合方案——每天导出一致性 SQL 文件至 Cloud Storage 并设置Bucket 保留策略 45 天，同时把binlog/WAL通过gsutil rsync到Archive桶；恢复时先全量导入，再用mysqlbinlog/pg_walreplay手动重放，超出托管部分需自己写编排脚本，RTO 会从 15 分钟延长到 1 小时左右。
2. 国内双11、618 大促场景，流量瞬间翻倍，日志生成速度提高 5 倍，保留期不变会导致存储费用暴涨，如何优化？
   答案：提前把保留期临时缩短至 3 天，同时增加全备频率（每天 2 次），用更密的快照换取更短的日志链；大促结束后再调回 30 天，费用可下降 40% 且 RPO 仍保持分钟级。
3. 面试官追问：“如果误删了一张核心表，发现时已经过去 36 小时，但保留期只设了 1 天，还有什么救命办法？”
   答案：立即关停写入避免日志轮转，提工单给Google Cloud 国内技术支持，后台冷存储层仍可能保留未 GC 的 WAL 片段；在 24 小时内工程师权限可手工捞回日志，成功率约 60%，但需现场按小时付费并签署数据保密协议——这是最后一根救命稻草，也再次证明保留期不可随意缩短。