一篇读懂灰度数据迁移：不停机改表与数据回填

数据迁移的三类场景

「数据迁移」在后端的日常里是三类高频场景：场景一：DDL 变更（加字段、改索引——「DDL 的锁」（MySQL 的 DDL 锁风险（大表的 ALTER 长时间锁表——「停机做 DDL」的时代结束（业务 7×24——不停机 DDL 的技术）；场景二：数据回填（新字段需要给存量数据回填值——「大表回填」的风险（一次 UPDATE 一亿行——锁与主从延迟——「分批回填」的技术）；场景三：存储迁移（迁库、迁云、分库分表的落地（「新旧库的双写切换」**——迁移的完整切换流程。

三类场景的共性：「业务不停 + 数据一致 + 可回滚」——这篇逐一拆解。

场景一：不停机的 DDL

MySQL 原生的在线 DDL（InnoDB 的 online DDL——「online DDL 的能力」：ADD COLUMN（ALGORITHM=INPLACE——「inplace 的限制」（部分 DDL 仍锁表（改列类型——「ALGORITHM 与 LOCK」的参数（显式指定算法——「DDL 的行为矩阵」（每种 DDL 的算法与锁级别——「先查矩阵再执行」的纪律。「online DDL 的问题」：DDL 的执行时间（大表的 in-place 也要时间——「DDL 期间的阻塞」（online DDL 需要一个 MDL 锁（元数据锁——「MDL 锁的灾难」（长事务持锁 → DDL 等 MDL → 「后续所有查询排队」——DDL 等待期间，该表的所有操作被阻塞——「MDL 的雪崩」是 DDL 最经典的线上事故——「长事务与 DDL 的互斥」：DDL 前检查长事务（「information_schema 的长事务查询」——杀掉或等待长事务结束。gh-ost 与 pt-online-schema-change：工具化的在线 DDL——「工具的原理」：影子表（新建影子表→同步原表数据→原子改名——「触发器 vs binlog」：pt-OSC 用触发器同步增量（「触发器的开销」——gh-ost 用 binlog 同步（「gh-ost 的优势」：无触发器、可暂停、可限速——「gh-ost 的流程」：建影子表→异步同步全量→追 binlog 增量→「cut-over」（原子改名切换——「cut-over 的瞬间」（改名的一刻的锁——「gh-ost 的限速」（主从延迟的自适应限速——「从库延迟」的保护。「DDL 的最佳实践」：低峰执行、检查长事务、用 gh-ost 做大表、「DDL 的回滚预案」（gh-ost 的回滚（影子表删除即可——「原表未动」的安全性——「DDL 的演练」**（生产前先在测试环境跑一遍。

场景二：大表的数据回填

「回填」的风险：一次性 UPDATE 的灾难（UPDATE table SET new_field=xxx WHERE new_field IS NULL——亿级表的 UPDATE——「锁的灾难」：长事务的行锁——主从延迟爆炸（「主从延迟」的灾难（从库延迟小时级——读流量读到旧数据——「binlog 的洪峰」（单次 UPDATE 的 binlog 巨大——「回填的正确姿势：分批」：「分批的参数」：每批 N 行（1000-10000）、批间间隔（「间隔的调节」（按主从延迟动态调节——「主从延迟」作为回填的节流器——延迟超阈值就暂停——「回填的动态调速」。「回填的实现」：脚本化的分批回填（「游标分批」（按主键分段的游标——「回填的断点续传」（记录进度（「进度表」——中断后从断点继续——「回填的幂等」（WHERE 条件的幂等（只更新 NULL——重跑安全——「回填的监控」（进度、主从延迟、耗时——「回填的可视化」。「回填的业务策略」：「新数据先行」（新写入的带新字段值——「双轨期」（新旧数据共存——「双轨期的查询兼容」（字段为 NULL 时的兜底逻辑——「双轨期」的长度（回填完成即结束——「回填完成的验证」（NULL 的占比监控。

场景三：迁移的双写切换

「双写切换」的四步流程：步骤一：开双写（新旧库同时写——「双写的实现」：代码层的双写（「双写的顺序」（先写旧库（旧库为权威——「双写失败的处理」（一边失败怎么办（「双写的一致性」——双写的一致性问题（对账系统的兜底（库内对账篇——「双写的事务」（跨库的双写无法事务——「补偿」的机制。步骤二：存量迁移（历史数据迁到新库——「迁移的校验」（count 对比+抽样对比——「迁移的对账」——「增量追平」（存量迁完后追增量——「追平的判断」（延迟降到秒级。步骤三：切读（读流量切到新库——「灰度切读」（按比例切读（1%→10%→100%——「切读的验证」（每步的验证（数据正确性、性能——「灰度切读」的节奏。步骤四：切写与下线（写流量切新库——「切写」的原子性（切写的瞬间（双写变单写——「切写的窗口」（低峰执行——「回滚的预案」（切写后的问题——「回滚的路径」（切回旧库（旧库数据的完整性——「旧库的保留期」（双写期间旧库一直在写——回滚的数据是完整的——「回滚窗口」的时长（切写后旧库的保留期（1-2 周——「下线」的最后一步。「迁移的演练」（迁移流程的预演（「预演环境」（全流程的演练——「演练的发现」（脚本 bug、流程缺陷——**「迁移演练」的强制。

数据迁移的进阶：gh-ost 的原理深挖与「迁移的监控」

数据迁移的进阶：gh-ost 的原理深挖与迁移全程的监控体系。「gh-ost 的原理深挖」：「gh-ost 的 cut-over」：切换的原子操作（「cut-over 的机制」（rename 的原子性——「cut-over 的锁」（切换瞬间的锁等待——「cut-over 的时机选择」（低峰执行——「cut-over 的重试」（锁竞争的重试机制——「cut-over 的失败处理」（失败后的状态（影子表还在、可重试——「cut-over」是 gh-ost 最精妙的设计。「gh-ost 的限速机制」：「限速的依据」：主从延迟（「延迟的自适应」（延迟超阈值自动降速——「限速的参数」（max-load、max-lag-millis——「限速的调优」——「节流器」的设计（「throttle」的开关——「手动节流」的应急（「暂停」的紧急操作——「gh-ost 的运维友好」是其被广泛采用的原因。「迁移的监控体系」：「迁移的全程监控」：「监控的维度」：数据同步的进度（「进度的可视化」——主从延迟的监控（「延迟的曲线」——业务影响的监控（「业务指标」的观察（DDL 期间的错误率——「迁移的告警」（延迟超限、进度停滞——「迁移的 dashboard」（迁移状态的可视化大盘——「迁移的可视化」让运维安心。「迁移的风险预案」：「迁移的风险清单」：长事务阻塞（「长事务的检查」（迁移前后的检查——主从延迟过大（「延迟的降速应对」——磁盘空间的不足（「空间的预检」（影子表的空间——「空间」的容量规划——「风险的预案」（每个风险的应对步骤——「风险清单」的演练。数据迁移的进阶总结：gh-ost 的 cut-over 原子切换+自适应限速（主从延迟节流）+迁移的全程监控（进度/延迟/业务）+风险清单与预案——「数据迁移」的工程成熟度=「工具的选择（gh-ost）×流程的完备（四步切换）×监控的覆盖（全程可视）×预案的充分（风险清单）」——每一次迁移都是一次「小的变更发布会」——流程、监控、预案，一个都不能少——**「迁移无小事」是数据工程师的第一信条。

数据迁移高频问答

收尾前回答三个高频问题。「gh-ost 迁移中途业务高峰来了怎么办？」——限速的自适应：「高峰的应对」：自动限速（主从延迟的自适应节流——「gh-ost 的 max-lag」（延迟阈值——「手动暂停」（gh-ost 的 no-op 暂停——「暂停的时长」（高峰过后继续——「迁移的暂停-恢复」是 gh-ost 的运维优势——「迁移的窗口」（低峰执行的规划——「迁移的跨天」（多天完成的常态——「迁移的耐心」。「双写期间数据不一致了怎么修复？」——对账的兜底：「双写的不一致」：一边成功一边失败——「不一致的发现」（对账任务——「修复的方向」：以权威库为准——「权威库」的判定（切换前旧库、切读后新库——「修复的工具」（对账平台的自动修复——「修复的幂等」——「不一致的止损」（双写的问题要快速修——「双写的一致性」是迁移的核心风险——「对账」是迁移的安全网。「迁移后老库还要不要保留？」——保留期的设计：「老库的保留」：回滚窗口（「回滚的窗口」（1-2 周——「回滚的场景」（新库的问题——「回滚的成本」（切回的流程——「保留的成本」（双倍的资源——「保留期」的结束（「下线」的仪式——「归档」的替代（「归档」比删除安全——「老库的下线」是迁移的最终章。数据迁移的问答收束：数据迁移的三个心智模型——「双写是保险丝（两边都有数据）、对账是安检仪（不一致必现形）、切读是临床试验（逐步扩大样本）」——「迁移的每一步都要有「回滚键」——「回滚键」的存在让迁移的胆子更大——**「胆子大」建立在「预案全」之上。

小结

数据迁移的三类场景与方案：不停机 DDL（原生 online DDL 的能力与 MDL 雪崩的风险、gh-ost 的影子表+binlog 方案——无触发器、可限速、可回滚——大表 DDL 的标配）；大表回填（分批+动态调速——「主从延迟作为节流器」、断点续传、幂等条件、双轨期的查询兼容）；双写切换（「双写-存量迁移-灰度切读-切写下线」四步——每步的验证与回滚预案——旧库保留 1-2 周的回滚窗口）。三类场景的共同哲学：「把大动作切成小动作，让每一步都可验证、可回滚」——不停机迁移不是「一次性的豪赌」，是「无数个可回滚小步骤的串联」——每一步的回滚预案，是迁移工程师的安全绳。给执行者的检查清单：DDL 前查长事务了吗？回填有断点续传吗？双写的一致性有对账吗？切读是灰度的吗？旧库保留了多久？——五个问题全过，迁移才敢动手。

数据迁移的最高境界：业务方全程无感知——他们只知道某天系统多了个新字段，而背后是一次搬动亿行数据的手术。