数据库分库分表后，我们生产环境怎么实现不停机数据迁移

昨天我们讲解了数据库分库分表后我们怎么去生成主键唯一ID（数据库分库分表后，我们怎么保证ID全局唯一），到目前为止我们已经掌握分库分表的策略了也会搭建统一发号器进行生成唯一ID。

现在有个问题就是，我们的线上已有数据目前都是在单库单表里面，这个现有线上的库表数据肯定是未经过分库分表的。而我们该怎么将这些数据使用到我们现在的多库多表上来呢？那么，今天我们就来讲一讲我们的分库分表该怎么来部署生产环境。一般会有两种方案，一个将我们的系统停止对外服务，另一个则是系统不停机，依然要将数据进行迁移到新的分库分表中。下面我们来看看这两种方案该怎么去实施。

01

停机部署

我们最先想到的方法应该就是停机部署了吧，在前几年我们做些数据库的跑批啥的也都是这么干的。也就是说将我们的对外服务给停掉，然后在我们的APP上或者是网站上挂上通告，说我们在0点到6点需要进行系统升级，在此期间暂停服务啥的。总之，就是在我们暂停服务的那段时间里需要告知用户一下。那我们应该怎么做呢？

1. 停机挂通告
2. 我们再写一个后台程序，这个程序用来从我们的目前数据库中查询出所有的数据，然后通过我们之前做好的分库分表策略，加上我们的数据库中间件，用嵌入代码的shadding-jdbc 或者是代理层的Mycat 又可以，将这些数据进行hash路由到我们的新分的库表中去。
3. 等都迁移到了新的多库多表中后，再将我们的线上代码数据源配置进行修改成连接我们的数据库中间件上，最后再重新启动服务就行了

有什么缺点：

• 系统必须进行停机一段时间
• 如果在规定的一段时间内并未完成数据的迁移，就需要回滚，重新切回原库。
• 我们开发人员比较疲惫

这样的停机部署方案比较直接，如果你们的系统可以接受短暂几个小时的停机，是可以采用这种方式的。但是如果不能接受的话，我们就需要在不停机的条件下将数据给迁移到新的库表中去，下面我们来看看不停机数据迁移方案。

02

不停机部署

在不停机条件下需要对数据的迁移，这里推荐我们常用的一种方案，也就是在线双写的机制。

1. 通过在写原有的数据库的同时也写一份数据到我们的新的库表中。
2. 同样写一个后台迁移数据的程序，将我们的旧库的数据通过我们的数据库中间件迁移到新的多库表中。
3. 在迁移的过程中，每次插入数据的时候，还需要检测数据的更新情况。比如，如果新的表中没有当前的数据，则直接新增；如果新表有数据并没有我们要迁移的数据新的话，我们就更新为当前数据，只能允许新的数据覆盖旧的数据。
4. 经过一轮之后，也就是假如旧表中1000万条旧数据迁移完之后，我们就需要进行校验，校验两边数据是否是一模一样的。
5. 这样反复的跑了几天之后，就数据库和新的数据库肯定是会一模一样的，最后观察下数据正常了，就可以停掉旧库的写入动作了。

总结，今天我们讲解了我们该怎么针对生产环境数据进行分库分表迁移，一共讲到了两种方案，停机部署迁移数据和不停机部署迁移数据。从目前的互联网行业来看，选择不停机迁移数据是一种比较合理的生产环境分库分表迁移方案，即将在线双写机制然后联合后台数据迁移合理运用，就能达到很好的实现分库分表方案。