共计 1356 个字符，预计需要花费 4 分钟才能阅读完成。
最近的工作在做业务库迁徙，如何做到平滑迁徙，保持数据一致性，尽量不停服是迁徙工作谋求的指标。本文分享一些数据迁徙工作常见计划以及当中须要留神的点。
先说下数据迁徙当中须要留神的点：
集体了解最重要的应该是数据的一致性，说的直白点，就是在数据迁徙当中，怎么保证数据不失落（大部分业务零碎的访问量很高，即使在凌晨两三点也有肯定的访问量，在迁徙当中怎么保障写入的数据不失落至关重要）。
其次重要的是迁徙步骤当中的执行程序，比方是先改 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=2，而后再设置从库）
B. 从库数据数据追上后，闲时停服，将从库降级为主库，将业务 DB 指向新的主库
C. 查看旧库上是否还有流量
D. 启动服务
这种形式的成本低，操作性强，但须要停服一会儿。
2. 双写，适宜场景：数据结构不同，我的项目中常常用到，罕用于重构某个性能导致的数据结构变动的迁徙。具体操作：
A. 新旧库同时写入（增删改）
B. 公布新代码前，先全量同步一次数据到新库，公布实现后，再增量对账（对账脚本）一遍新旧库数据（次要针对公布当中，因为滚动更新新旧代码共存期间产生的局部数据只写了旧库，没有写新库的状况），或者依据 modified 或 created 字段，增量同步此段时间产生的数据，当然也要视双写代码的具体实现而定，如果双写每次新库都是删除后新增的话，可能就没有必要第二次的对账。如果双写要思考性能，能够用 MQ 等异步队列的形式写新库。
C. 通常为了验证双写的正确性，能够采纳灰度的形式，让局部流量切到新库，直到稳固后，才全量新库。
3. 利用 Canal 和 DTS 等数据同步工具做数据同步
4. 利用 MHA 高可用计划做 mysql 迁徙（对外 vip 不变，业务层不须要改变）
以上就是一些数据迁徙的惯例计划。
专一 Web 开发、后盾开发、DB 性能及架构
我的公众号“码农漫谈”，如果喜爱我的文章，能够关注公众号，打工不易：（，欢送技术沟通与交换，每天提高一点点