解读

在国内真实业务场景里，最小停机≈秒级中断，核心诉求是业务连续性与数据一致性兼得。DMS 本质是托管式“逻辑复制+CDC”，通过 change streaming 把源库增量实时推送到 Cloud SQL，再借助 promote 动作完成角色切换。面试官想听的是：你对“全量→增量→校验→切换”四段式流程的掌控度，以及能否在合规、网络、回退、灰度四个维度给出可落地的中国方案。

知识点

1. DMS 架构：Agentless 设计，源端仅需开启 binlog/pglogical；数据流走 VPC Peering/专线/CCA-GA（全球加速），不落地 GCS。
2. 迁移对象粒度：可细化到 库、表、列、WHERE 条件，支持 分区表拆分 与 字符集转换。
3. 一致性保障：MySQL 用 ROW+GTID，PostgreSQL 用 logical replication slot，SQL Server 用 CDC + LSN；均支持 exactly-once。
4. 停机窗口计算：promote 耗时 = 最后一条增量 Apply 时间 + DNS/TCP 健康检查漂移时间 + 应用重连池刷新时间，国内实测 <10 s。
5. 合规与回退：必须提前申请 跨省跨境数据流动评估；回退方案采用 反向 DMS 链路 或 DTS 双写，RPO≤5 min。
6. 观测指标：重点关注 Replication Lag < 1 s、Apply 延迟 < 500 ms、冲突错误 0、连接数突降 0。

答案

第一步，预检与优化。在源库打开 binlog_row_image=FULL、max_replication_slots≥10，并创建 独立复制账号（mysql.sys@'%' 或 dms@'%'）。对超大表提前做 pt-online-schema-change 把碎片降到 <30%，避免全量阶段 I/O 抖动。
第二步，创建连接配置。国内若源在阿里云 ECS，建议走 专线+Private Service Connect；若在本地 IDC，用 HA VPN + BGP 高可用隧道，带宽按 峰值 QPS×1.5 倍 预留，并开启 Cloud Router 流控 防止丢包。
第三步，启动全量。选择 “一致性快照” 模式，DMS 会自动加 FLUSH TABLES WITH READ LOCK <3 s，随后把数据拆成 8 并发 chunk 并行导入；对 500 GB 级别库，全量约 30 min。
第四步，增量追平。全量结束后 DMS 立即启动 CDC 任务，此时在 Cloud Monitoring 建立 自定义仪表盘：lag 指标选 cloudsql.googleapis.com/database/replication/replica_lag；当 lag 持续 <1 s 超过 15 min，即可进入割接窗口。
第五步，业务割接。

1. 在应用层配置 双写开关（Feature Flag），先禁写 3 s，确保 last GTID 已 Apply；
2. 通过 Cloud DNS 私有区 把域名 db-prod.internal 从旧 A 记录 10.0.0.10 切到 Cloud SQL Private IP 10.1.0.20，TTL 设为 5 s；
3. 开启应用重连池 testOnBorrow=true，30 s 内完成漂移；
4. 观测 连接数、错误日志、订单接口成功率，确认无误后释放源库写锁，停机窗口 <10 s。
   第六步，反向回退。保留源库 7 天 并开启 反向 DMS 链路，若发现数据异常，30 s 内可切回；同时把 Cloud SQL 备份窗口调到 北京时区 03:00-04:00，与源库保持一致，方便审计。

拓展思考

1. 双活架构：如果业务要求 零停机，可在割接后让应用继续 双写 24 h，通过 DMS 反向链路 做 冲突检测（last-writer-win），再逐步下线旧库。
2. Serverless 场景：Cloud SQL 开启 只读实例 做灰度读流量，利用 IAM Conditions 让新功能只访问新库，降低风险。
3. 成本优化：全量阶段使用 Preemptible VM 作为 DMS Worker，可节省 70% 计算费；但需设置 重试策略 防止 Worker 抢占失败导致任务重启。
4. 国产化合规：若源库含 个人信息，需提前在 DMS 配置列级哈希（SHA-256+盐），并走 GDPR 模板 生成 PIA 报告，满足 《个人信息保护法》第 38 条 跨境评估要求。