为什么要做数据迁移？

很多场景会导致我们需要修改表结构，当alter不支持修改或者说alter导致的锁表代价太大的时候，我们就需要做数据迁移来解决。

典型的需要做数据迁移的例子，就是当业务快速发展，单表无法支撑业务数据，需要对单表做拆分，做分库分表时，我们需要把单表的数据全部迁移到新的库和表当中。

其次就是经过了一段时间之后，需求有很大变化的时候，需要扩充单表字段。单纯的alter对于有很多数据的单表并不友好，会导致单表被锁，线上写请求超时，这有时是不可容忍的。

所以我们需要有数据迁移，数据迁移往往对应的是需求的变化、业务的增长。

怎么做数据迁移？

想象一下我们如果要做数据迁移会有哪些步骤。

1.逐行读取线上表的数据
2.根据业务需要，对每行数据做特殊处理
3.数据逐行写入到新的表中
4.线上切换到新的数据表

看起来很简单，但是这里有一个问题需要解决。

如何实现无缝迁移？

在读取线上表的过程中，有可能出现线上表数据被update的情况。此外，读取完成线上表之后，有可能出现线上insert数据的情况。最后结果就是同步数据过程中就会马上出现新表和旧表数据不一致的地方。这个时候就需要应用停机来保证新表和旧表数据一致。但是如果不能接受长时间的停机，那该怎么办呢？

可以考虑的方案是，在开始进行数据迁移时，记录增量日志，在迁移完成后，再对增量日志做处理。在最后，可以把要被迁移的数据的写暂停(应用停机)，保证增量数据都处理完成后，再切换数据源，放开所有的写，完成迁移工作。

下面是一些实现数据迁移的具体方案：

方案一 定点停机迁移

在一个月黑风高的夜晚，停掉应用，用事先写好的迁移程序，把mysql 数据库数据迁移到新结构的mysql数据库中。完成后，切换应用。最大的缺点就是随着数据量的增加停机时间会变得非常长。

停机到底会有多长? 几千万的数据，也许一个晚上就能搞定(大部分游戏的停机维护时间)。亿级别的数据，也许就需要几天了，拥有这么大数据量的业务，一般是无法忍受这种量级的停机维护的。

方案二 MySQL binlog方案

MySQL的迁移可以考虑MySQL的主从复制Replication的特性，解析binlog日志，根据业务需要，对每行数据做特殊处理，把数据写入到新的数据库，运行迁移过程不需要停机。在数据迁移基本上完成的时候，停掉应用，等待迁移全部完成，切换应用到新库。停机时间非常短，只需要几乎1-2分钟或者更少。

方案三 触发器方案

备份老的MySQL数据表结构到新的MySQL数据库，在新库创建新的表结构，更改老的数据库表，创建触发器，让数据写入的时候同时写入到的新的MySQL表。dump老的MySQL的数据，导入到新的MySQL，这是新的MySQL表结构的表应该已经有相应的数据了。然后开启主从复制，让其达到跟主库数据一致。切换应用，迁移到的方案。停机时间非常短，只需要几乎1-2分钟或者更少。

这种方案一般适用于小型公司，不太适用于大公司。因为在大一点的公司，数据库管理由专门的DBA负责，业务开发人员不会有权限去MySQL服务器上去写触发器。即使可以提交工单，让DBA来全权操作，但是明明可以业务自己处理的东西，干啥每次都要劳烦DBA呢是吧:)，人力成本也是成本。

方案四 中间件方案

这种方案必须要你的应用连接数据使用了类似中间层的方案，你只需要在中间层增加同时往新库写数据的代码就好了。

参考文献:
MySQL数据库的无缝迁移