100亿数据，非“双倍”扩容，如何不影响服务，数据平滑迁移？

步骤一中日志里记录的，正是变化的数据。

步骤三：研发一个读取日志并迁移数据的小工具，要把步骤二迁移数据过程中产生的差异数据追平。这个小工具需要做的是：

(1)读取日志，得到哪个库、哪个表、哪个主键发生了变化;

(2)把旧库中对应主键的记录读取出来;

(3)把新库中对应主键的记录替换掉;

无论如何，原则是数据以旧库为准。

这个小工具的风险也很小：

(1)整个过程依然是旧库对线上提供服务;

(2)小工具的复杂度较低;

(3)任何时间发现问题，大不了从步骤二开始重来;

(4)可以限速慢慢重放日志，技术同学没有时间压力;

日志重放之后，就能够切到新库提供服务了么?

答案依然是否定的，在日志重放的过程中，旧库中又可能有数据发生了变化，导致数据不一致，所以还是不能切库，需要进一步读取日志，追平记录。可以看到，重放日志追平数据的程序是一个while(1)的程序，新库与旧库中的数据追平也会是一个“无限逼近”的过程。

什么时候数据会完全一致呢?

步骤四：在持续重放日志，追平数据的过程中，研发一个数据校验的小工具，将旧库和新库中的数据进行比对，直到数据完全一致。

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

(1)整个过程依然是旧库对线上提供服务;

(2)小工具的复杂度较低;

(3)任何时间发现问题，大不了从步骤二开始重来;

(4)可以限速慢慢比对数据，技术同学没有时间压力;

步骤五：在数据比对完全一致之后，将流量迁移到新库，新库提供服务，完成迁移。

如果步骤四数据一直是99.9%的一致，不能完全一致，也是正常的，可以做一个秒级的旧库readonly，等日志重放程序完全追上数据后，再进行切库切流量。

至此，升级完毕，整个过程能够持续对线上提供服务，不影响服务的可用性。

方案三：双写方案

双写方案，也是一个高可用的平滑迁移方案，这个方案主要分为四个步骤。

数据迁移前，上游业务应用通过旧的服务访问旧的数据。

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

(1)旧库与新库的同时insert;

(2)旧库与新库的同时delete;

(3)旧库与新库的同时update;

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

这个服务升级风险较小：

(1)写接口是少数接口，改动点较少;

(2)新库的写操作执行成功与否，对业务功能没有任何影响;

步骤二：研发一个数据迁移工具，进行数据迁移。这个数据迁移工具在本文中已经出现第三次了，把旧库中的数据转移到新库中来。

这个小工具的风险较小：

(1)整个过程依然是旧库对线上提供服务;

(2)小工具的复杂度较低;

(3)任何时间发现问题，都可以把新库中的数据干掉重来;

(4)可以限速慢慢迁移，技术同学没有时间压力;

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

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

（编辑：济南站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!