解读

在国内云原生场景里，面试官问“Backfill 与流模式的一致性差异”，并不是让你背概念，而是想确认三件事：

1. 你是否理解两种模式在时间维度上对“一致”这个词的定义不同；
2. 你是否能把差异落到Google Cloud SQL 可观测的指标（如 replication lag、transaction ID 可见性）上；
3. 你是否能给出业务可落地的选型建议，而不是空谈理论。
   因此，回答必须围绕“可见性边界”“延迟窗口”“回滚能力”三个关键词展开，并主动把 Cloud SQL 的只读实例、外部复制、Database Migration Service（DMS）等真实产品模块带进来，让面试官一听就知道你“用过”。

知识点

1. Backfill 模式：

   • 本质是一次性批量快照导出导入，常见工具包括 mysqldump、pg_dump 以及 DMS 的“一次性全量迁移”作业。
   • 一致性锚点是导出开始那一刻的 binlog/WAL 位点；导出期间源库新提交的事务不会进入该快照。
   • 在 Cloud SQL 内部，如果源实例开启一致性快照导出（即 –single-transaction 或 pg_dump –snapshot-too-new），所有表读到的是同一事务 ID 下的版本，因此快照内部是强一致的；但快照与源库“当前最新数据”之间必然存在时间漂移。
   • 失败重跑代价高：大表需要重新导出，没有断点续传。

2. 流模式：

   • 指持续读取源库binlog（MySQL）或 WAL（PostgreSQL），通过 Cloud SQL 外部复制或 DMS“持续同步”链路，把变更事件顺序重放到目标。
   • 一致性由复制位点（GTID/LSN）保证，只要 lag=0，目标库与源库就是事务级最终一致；lag>0 时存在秒级甚至分钟级不一致窗口。
   • 支持断点续传，网络抖动后可从上次位点继续，无需重跑全量。
   • 在 Cloud SQL 只读实例场景里，流模式就是原生异步复制，最大可靠性 SLA 承诺 99.95%，但不保证零数据丢失（RPO≥0）。

3. 一致性差异总结：

   • Backfill 提供的是静态点一致，但点与点之间不连续；流模式提供的是动态最终一致，连续但存在滞后。
   • 业务侧如果要做“切换前校验”，Backfill 只需比对新旧库快照 checksum；流模式则必须等 lag=0 并做双向对账，否则切流后可能出现少数据或重复写。

答案

“在 Google Cloud SQL 的实践中，Backfill 模式与流模式的最大一致性差异体现在可见性边界与延迟窗口两方面。
Backfill 通过一次性快照导出，把源库在某一固定 binlog/WAL 位点的完整镜像搬到目标，因此目标内部是强一致的，但导出过程不感知源库后续新事务，导致目标与源库实时数据存在时间漂移；如果业务要求‘快照级绝对一致’，Backfill 是首选，但需要接受停机窗口或只读锁表代价。
流模式则持续消费源库增量日志，把事务按提交顺序重放到目标，当复制 lag 归零时，目标库与源库达到事务级最终一致；然而在网络抖动或大事务场景下，lag 可能从几秒到几分钟不等，此时读目标库会漏掉最新数据，写操作若直接切流则存在数据丢失风险。
因此，做零停机迁移时，行业通用做法是先 Backfill 全量、再切流追增量，等 Cloud SQL 监控面板显示‘Replication lag = 0 且 GTID 无缺口’后，才把写流量切换到新库，从而把一致性风险降到最低。”

拓展思考

1. 如果源库是 MySQL 8.0，开启 binlog_transaction_compression，流模式重放时可能出现瞬时 CPU 飙高，如何提前评估 Cloud SQL 目标实例规格？
2. 国内金融监管要求RPO=0，但 Cloud SQL 外部复制默认异步，是否考虑用跨区域高可用主从（HA + Regional Disk）替代流模式？
3. 当目标库为 PostgreSQL 且需要逻辑解码时，Backfill 后若源库出现大事务回滚，如何验证 toast 表与索引在目标端仍checksum 一致？