如何在迁移过程中保持数据一致_mysql一致性控制

MySQL 迁移数据一致性需分阶段控制写入、校验差异、灰度切换；通过 GTID 同步增量、mysqldiff 校验结构与内容、只读过渡及回滚预案保障全程一致。

迁移过程中保持 MySQL 数据一致性，核心在于 控制写入、校验差异、分阶段切换 。不能只依赖 工具 自动同步，必须主动设计一致性保障机制。

停写或读写分离过渡

最直接的方式是迁移前暂停业务写入（停机迁移），适合可接受短时中断的场景。若需持续服务，应将应用切换为只读，或通过中间件 / 代理把新写入 路由 到新库（双写），同时确保旧库不再接受变更。

• 使用 FLUSH TABLES WITH READ LOCK 获取一致快照（注意锁表影响）
• 主从架构下可在从库上拉取备份，避免锁主库
• 若用双写，需严格保证新旧库写入顺序和事务完整性，推荐用可靠消息队列解耦

基于 GTID 或位点的增量同步对齐

全量迁移后，必须追平迁移期间产生的增量数据。优先使用 GTID（MySQL 5.6+），它能明确标识每个事务，避免位点解析错乱。

• 记录源库迁移开始时刻的 SELECT @@GLOBAL.GTID_EXECUTED
• 目标库开启 gtid_mode=ON，用 CHANGE MASTER TO …… GTID_SET = 'xxx' 指定起始点
• 同步完成后执行 SELECT MASTER_POS_WAIT() 确认追平，再比对 GTID 集合是否完全一致

结构与内容双向校验

同步完成不等于数据一致。要验证表结构、行数、关键字段哈希值是否匹配。

• 用 mysqldiff 或 pt-table-checksum（Percona Toolkit）校验主从 / 新旧库间数据差异
• 对大表分块校验（如按主键范围），避免单次查询超时或内存溢出
• 重点检查逻辑主键、时间戳、状态字段等易受业务逻辑影响的列

灰度切换与回滚预案

切流不是一次性动作。先将部分流量（如测试用户、低峰时段请求）导向新库，观察日志、延迟、错误率；确认无异常后再逐步扩大比例。

• 保留旧库至少 24–48 小时只读，作为应急回退依据
• 提前准备回滚 SQL 脚本（如反向同步、数据还原语句），并演练执行路径
• 监控项至少包括：QPS、慢查数量、复制延迟、连接数、主键冲突告警

一致性不是迁移结束才验收的结果，而是贯穿准备、执行、验证、切换全过程的约束条件。