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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

方案三：双写方案

（编辑：西安站长网）

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