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

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

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

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

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

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

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

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

这个服务升级风险较小：

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

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

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

这个小工具的风险较小：

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

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

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

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

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

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

由于迁移数据的过程中，旧库新库双写操作在同时进行，怎么证明数据迁移完成之后数据就完全一致了呢?

如上图所示：

(1)左侧是旧库中的数据，右侧是新库中的数据;

(2)按照primary key从min到max的顺序，分段，限速进行数据的迁移，假设已经迁移到now这个数据段，数据迁移过程中的修改操作分别讨论：

假设迁移过程中进行了一个双insert操作，旧库新库都插入了数据，数据一致性没有被破坏

假设迁移过程中进行了一个双delete操作，这又分为两种情况

情况一：假设这delete的数据属于[min,now]范围，即已经完成迁移，则旧库新库都删除了数据，数据一致性没有被破坏;

情况二：假设这delete的数据属于[now,max]范围，即未完成迁移，则旧库中删除操作的affect rows为1，新库中删除操作的affect rows为0，但是数据迁移工具在后续数据迁移中，并不会将这条旧库中被删除的数据迁移到新库中，所以数据一致性仍没有被破坏;

假设迁移过程中进行了一个双update操作，可以认为update操作是一个delete加一个insert操作的复合操作，所以数据仍然是一致的

除非，在一种非常极限的情况下：

(1)date-migrate-tool刚好从旧库中将某一条数据X取出;

(2)在X插入到新库中之前，旧库与新库中刚好对X进行了双delete操作;

(3)date-migrate-tool再将X插入到新库中;

这样，会出现新库比旧库多出一条数据X。

但无论如何，为了保证数据的一致性，切库之前，还是需要进行数据校验的。

步骤三：在数据迁移完成之后，需要使用数据校验的小工具，将旧库和新库中的数据进行比对，完全一致则符合预期，如果出现步骤二中的极限不一致情况，则以旧库中的数据为准。

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

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

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

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

（编辑：西安站长网）

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