前期准备

在进行数据迁移之前，一定要做好迁移前的准备。

• 环境调研，源和目标数据库环境、版本、数据量大小、业务场景、操作系统版本等
• 方案准备，尽量详细、迁移失败导致源数据库挂了是否有数据备份回退方案
• 人员角色到齐，数据迁移放在晚上，最好是A/B角色一起参与。
• 对业务影响范围充分了解，对源数据用monitor命令查看有哪些ip进行了操作(过虑掉ping、info、slowlog的ip)，host转为域名
• 停机窗口、这段时间要是出现问题怎么处理

检查

• 对比源和目标的环境（info、uname -a命令）
• 了解业务的影响范围（monitor、wak、sort等命令，有哪些对源进行了crud）
• 人员备齐（开发、运维）
• 源数据的备份，万一迁移的时候源挂了
• 数据双写，在写源的时候，写一份到目标机器，采用先双写后面增量或者全量补充历史数据的方式。

平滑迁移-双写法方案

• 主要分为四个步骤。

• 步骤一：服务进行升级，对“对旧库上的数据修改”（这里的修改，为数据的insert, delete, update），在新库上进行相同的修改操作，这就是所谓的“双写”，主要修改操作包括：

  1. 旧库与新库的同时insert
  2. 旧库与新库的同时delete
  3. 旧库与新库的同时update

• 由于新库中此时是没有数据的，所以双写旧库与新库中的affect rows可能不一样，不过这完全不影响业务功能，只要不切库，依然是旧库提供业务服务。

• 这个服务升级风险较小：

  1. 写接口是少数接口，改动点较少
  2. 新库的写操作执行成功与否，对业务功能没有任何影响

• 步骤二：研发一个数据迁移工具，进行数据迁移，把旧库中的数据转移到新库中来。

• 这个小工具的风险较小：

  1. 整个过程依然是旧库对线上提供服务
  2. 小工具的复杂度较低
  3. 任何时间发现问题，都可以把新库中的数据干掉重来
  4. 可以限速慢慢迁移，技术同学没有时间压力

• 数据迁移完成之后，就能够切到新库提供服务了么？

  • 答案是肯定的，因为前置步骤进行了双写，所以理论上数据迁移完之后，新库与旧库的数据应该完全一致。

• 在一种非常非常非常极限的情况下：

  1. date-migrate-tool刚好从旧库中将某一条数据X取出
  2. 在X插入到新库中之前，旧库与新库中刚好对X进行了双delete操作
  3. date-migrate-tool再将X插入到新库中

• 这样，会出现新库比旧库多出一条数据X。

• 但无论如何，为了保证数据的一致性，切库之前，还是需要进行数据校验的

• 步骤三：在数据迁移完成之后，需要使用数据校验的小工具，将旧库和新库中的数据进行比对，完全一致则符合预期，如果出现步骤二中的极限不一致情况，则以旧库中的数据为准。

• 这个小工具的风险依旧很小：

  1. 整个过程依然是旧库对线上提供服务
  2. 小工具的复杂度较低
  3. 任何时间发现问题，大不了从步骤二开始重来
  4. 可以限速慢慢比对数据，技术同学没有时间压力

• 步骤四：数据完全一致之后，将流量切到新库，完成平滑数据迁移。
• 至此，升级完毕，整个过程能够持续对线上提供服务，不影响服务的可用性。

总结

针对互联网很多“数据量较大，并发量较大，业务复杂度较高”的业务场景，在

1. 底层表结构变更
2. 分库个数变换
3. 底层存储介质变换

的众多需求下，需要进行数据迁移，完成“平滑迁移数据，迁移过程不停机，保证系统持续服务”的解决方案。

• 双写法，四个步骤：

1. 服务进行升级，记录“对旧库上的数据修改”进行新库的双写
2. 研发一个数据迁移小工具，进行数据迁移
3. 研发一个数据比对小工具，校验数据一致性
4. 流量切到新库，完成平滑迁移