最近的工作在做业务库迁移，如何做到平滑迁移，保持数据一致性，尽量不停服是迁移工作追求的目标。本文分享一些数据迁移工作常见方案以及当中需要注意的点。
先说下数据迁移当中需要注意的点：
个人理解最重要的应该是数据的一致性，说的直白点，就是在数据迁移当中，怎么保证数据不丢失（大部分业务系统的访问量很高，即便在凌晨两三点也有一定的访问量，在迁移当中怎么保证写入的数据不丢失至关重要）。
其次重要的是迁移步骤当中的执行顺序，比如是先改db host，还是先迁移数据，还是先做其他什么操作？一般的过程大体是这样：
1.先选一个闲时，尽量还是选择用户操作少的时间段（比如凌晨），减少数据写入和读取
2.停掉定时任务&一些周边允许停止的服务组件（比如消费者MQ之类的），这一步的目的还是为了减少数据写入和读取，这一步视系统而定，鄙人迁移的过程，停掉定时任务是在允许范围内的。对于系统本身，绝大部分功能还是可用的，只有少部分功能可能受到影响，主体功能不受影响，系统提供有损服务。
3.dump mysql源库数据
4.将上一步得到的数据source到目标库
5.脚本检查数据迁移的正确性（数据量和库表是否符合预期）
6.将db配置指向新库【可能是改host, 可能是改db的方式，或许还需要配合发布等操作】（这一步不能提前到source之前，如果提前的话，从用户角度来看，存在数据丢失，从运维角度来看，会加大存量历史数据的处理难度，比如id冲突之类的）
【数据迁移方案汇总】7.检查流量是否全切到新库
8.开启定时任务等job服务以及其他周边服务组件
大体是上述流程，可能会根据具体系统不同而略有差异，以上就是迁移过程中需要注意的点，但是具体要怎么操作呢？比如上述第三步之后源库产生新的数据怎么破？
下面介绍一些数据迁移的一些常见方案：
1.主从同步的方式迁移数据。具体操作：
A. 给源库挂一个从库，开启主从同步（一般先全量dump --master-data=https://www.it610.com/article/2，然后再设置从库）
B. 从库数据数据追上后，闲时停服，将从库升级为主库，将业务DB指向新的主库
C. 检查旧库上是否还有流量
D. 启动服务
这种方式的成本低，操作性强，但需要停服一会儿。
2.双写，适合场景：数据结构不同，项目中经常用到，常用于重构某个功能导致的数据结构变化的迁移。具体操作：
A. 新旧库同时写入（增删改）
B. 发布新代码前，先全量同步一次数据到新库，发布完成后，再增量对账（对账脚本）一遍新旧库数据（主要针对发布当中，因为滚动更新新旧代码共存期间产生的部分数据只写了旧库，没有写新库的情况），或者根据modified或created字段，增量同步此段时间产生的数据，当然也要视双写代码的具体实现而定，如果双写每次新库都是删除后新增的话，可能就没有必要第二次的对账。如果双写要考虑性能，可以用MQ等异步队列的方式写新库。
C. 通常为了验证双写的正确性，可以采用灰度的方式，让部分流量切到新库，直到稳定后，才全量新库。
3.利用Canal和DTS等数据同步工具做数据同步
4.利用MHA高可用方案做 mysql迁移（对外vip不变，业务层不需要改动）
以上就是一些数据迁移的常规方案。
专注Web开发、后台开发、DB性能及架构
我的公众号“码农漫谈”，如果喜欢我的文章，可以关注公众号，打工不易：（，欢迎技术沟通与交流，每天进步一点点
文章图片
推荐阅读
- Java|java精尽面试题MySQL面试高频一百问（工程师方向）
- Mysql|MySQL 经典面试题(面试秘籍)
- Mysql 执行计划分析
- Mysql|MySQL经典100问
- Mysql开启log-bin日志
- mysql|索引键的长度对查询性能的影响
- mysql的锁
- mysql|mysql 插入语句语法_SQL 插入数据（INSERT INTO 语句）
- 数据库|TiDB Online DDL 在 TiCDC 中的应用丨TiDB 工具分享