解读

在国内企业上云实践中，从本地 MySQL 或腾讯云、阿里云 RDS 向 Google Cloud SQL 做在线迁移时，源库 binlog 保留期直接决定了回退窗口的上限。保留期太短，一旦迁移失败，Cloud SQL 已写入的数据无法与源库对齐，只能全量重导，造成业务长时间停写；保留期太长，又会挤占本地磁盘、增加运维成本。面试时，考官想听你如何把“保留期”与回退可行性、RPO 指标、磁盘容量、法律合规四条线串起来，给出可落地的权衡方案。

知识点

1. binlog 保留期：源库通过 expire_logs_days 或 binlog_expire_logs_seconds 控制文件生命周期，国内 MySQL 5.7 默认 7 天，8.0 默认 30 天。
2. CDC 位点：Cloud SQL 使用 gcloud sql import ... --sync-mode=continuous 时，会记录当前消费的 binlog file 与 position，失败重试依赖该位点仍在源库存在。
3. 回退路径：
   a. 增量回退——保留期 ≥ 预计修复时间，可直接重新启动迁移任务，RPO≈0；
   b. 全量回退——保留期 < 修复时间，必须重新做全量导出+导入，RPO 可能高达数小时。
4. 国内合规：等保 2.0 要求日志留存不少于 6 个月，但业务 binlog 与审计 binlog 需分层存储，不能把生产盘直接设 180 天，应通过NAS 冷备或对象存储生命周期策略 offload 历史文件。
5. 磁盘水位：国内自建机房常因 SSD 成本高，把 expire_logs_days 压到 3 天，迁移窗口被锁死 72 h，若遇到长节假日无法现场值班，极易出现“日志被 purge 掉”的致命场景。
6. Cloud SQL 自带防护：目标库在最后一次成功位点后，若源端 binlog 被 purge，任务状态会变为 FAILED_BINLOG_PURGED，此时 Google 侧无法自动回退，需要人工介入。

答案

“源库 binlog 保留期”是迁移失败回退的时间边界。保留期必须大于预计故障检测+修复+验证的时间之和，否则一旦源端 binlog 被 purge，Cloud SQL 记录的同步位点就会失效，只能放弃增量、重新全量导入，导致：

1. RPO 恶化：业务停写时间从分钟级拉长到小时级；
2. 成本放大：二次全量导出占用本地 I/O 与带宽，可能触发国内带宽峰值计费；
3. 合规风险：若全量导出期间跨越了监管报表时点，数据缺口需向央行或证监会书面说明。

因此，国内实施时我会把保留期设为**‘预计修复时间 × 2 + 1 天’** 作为底线，同时配置凌晨自动备份到低成本 OSS，既满足等保留存，又不挤爆本地盘。若源库磁盘紧张，可临时调大保留期并开启binlog 压缩，或采用Google Datastream 的 backfill 机制做兜底，确保失败回退始终可增量续传。

拓展思考

1. 如果源库是阿里云 RDS MySQL 5.6，只读实例延迟 2 h，主实例 binlog 保留期 18 h，如何设计回退策略才能保证 Cloud SQL 迁移失败后 RPO < 30 min？
2. 当业务方坚持**“零磁盘扩容”，而源库每日产生 500 G binlog，你会如何用NAS 挂载+硬链接**实现“热文件本地保留 3 天、冷文件 90 天”的分层方案？
3. 在跨境合规场景下，源库位于北京，Cloud SQL 位于新加坡，若国内法律要求日志不出境，如何把 binlog 保留期与数据驻留要求同时满足，又不影响增量回退？