MYSQL数据库 单表亿级数据不停机迁移

一 序

   根据业务规划，需要对于交易系统进行数据库优化，合规性要求是先进行数据库迁移，再做水平分库拆分。

一些表数据供参考：

           rows                                                 datasize                                                       indexsize

189788148

151586.000MB

60417.844MB

332440156

31122.016MB

16589.047MB

但从数据量来说，基本上是主键查询为主要场景，少部分走二级索引。不然MYSQL这么大的单表扛不住了。本次只关注第一步数据迁移。

二 准备工作

    1梳理原库的访问情况，主要是怕有迁库遗漏的，比如有数据同步的到大数据库平台的。平时业务不关注。这样一旦遗漏就容易丢失BI的出数据。从监控找出业务低峰期，预估操作时段。

   2. 提前告知dba,协助梳理出数据库访问的ip名单，方便加入到新库的ip白名单。

   3. 提工单准备新数据库RDS，告知性能及磁盘大小。我们都是用的阿里云的。即时阿里云磁盘扩容也很难受，比如宿主机磁盘满了，扩容需要中断30秒。所以尽量一开始就申请好，可以按照两年空间申请。

  4. 跟dba确认 迁移方案，购买dts链路。

  5.告知业务方，尤其是数据同步的BI侧，需要准备购买新的dts链路。

三 数据迁移方案

1. 程序准备双写，即配置双写开关、新球数据源切换开关。示意如下

2. dba开启dts数据同步。数据从旧库同步到新库。

   这个过程耗时较长，根据数据量评估。我们实际操作2亿条数据大概为10小时。

    达到这个就认为数据同步上来了，过程中不同check。就是看最新的数据的情况，所以这时候如果有id做主键或者创建时间有索引，就比较好对比数据。

3. 在业务低峰期操作。通常是半夜，但是不一定是12点，那时候反而有定时任务再跑。需要观察。

4. 打开双写开关（一日志生效为准）。同时dba停掉dts同步。秒级操作。这时候就是很快的了。前后一两秒吧。

  可能会有报错主键冲突之类，业务低峰期相对影响很低了。2秒之内。

5.校验数据。

  这时候从两个方面校验，一个是对比最新的数据，一个是总数量。

另外需要重点关注操作的前后的这1分钟内数据对比。当然这是人工的。几条出错心里有数。

6. 开始数据全量对比。

  新旧数据全量对比，如果差异，则以旧库状态为准。这个耗时较长，工具执行就行。

7. 上面的数据对比通过，则打开切换数据源开关。全面切到新库。通知业务方。从新库同步数据

   如果不通过，则切回就数据源查找原因。

8. 最后一步，下掉双写代码，配置等。

 

  不是很复杂，整个过程比较平滑，风险可控。

当然见过有的组把双写期间所有的写操作（insert、update）都打印出日志记录主键id，对比这个数据的。

实操经验：

 1 开双写接口耗时增加5ms正常。

 2. 数据追平后，新库不要立即切换。通过count(id)发现，单表2亿的数据库新库数据过来了，但是缓存没有生效，数据有个预热的过程。老库40秒，新库同样配置，同样数据要1分20秒，还是有显著差异。所以要通过一些手段预热数据，好了再切，基本上不是一天完成的。