1. 数据迁移

互联网架构，很多时候面临着这样类似的需求：

底层表结构变更：数据量非常大的情况下，数据表增加了一些属性，删除了一些属性，修改了一些属性。

分库个数变化：由于数据量的持续增加，底层分库个数非成倍增加。

底层存储介质变化：底层存储引擎由一个数据库换为另一个数据库。

如何平滑迁移数据，迁移过程不停机，保证系统持续服务，保证服务的可用性？

1.1. 停服迁移

停服扩容，是最容易想到的方案？

1. 通过对外挂出公告，某个时间段停止服务
2. 研发一个数据迁移工具，在停机过程中进行数据迁移工作
   1. 底层表结构变更需求：开发旧表导新表的工具；
   2. 分库个数变换需求：开发2库导3库的工具；
   3. 底层存储介质变换需求：开发Mongo导Mysql工具；
3. 恢复服务，并将流量切到新库，不同的需求，可能会涉及不同服务升级。
   1. 底层表结构变更需求：服务要升级到访问新表；
   2. 库个数变换需求：服务不需要升级，只需要改寻库路由配置；
   3. 底层存储介质变换需求：服务升级到访问新的存储介质；

这一方案有很明显的劣势：

1. 需要停止服务，只能对一些可以支持长时间不可用的应用使用，比如游戏停服
2. 因为限定了固定的时间，这对于前期的开发、测试，以及最终阶段的部署都有较高的要求，压力较大，难以处理突发状况，而人在压力越大的时候越容易出错
3. 如果有问题第一时间没检查出来，启动了服务，运行一段时间后再发现有问题，则难以回滚，如果回档会丢失一部分数据；

1.2. 追日志方案

步骤一：服务进行升级，记录“对旧库上的数据修改”的日志（这里的修改，为数据的insert, delete, update），这个日志不需要记录详细数据，主要记录：

• 被修改的库；
• 被修改的表；
• 被修改的唯一主键；

具体新增了什么行，修改后的数据格式是什么，不需要详细记录。这样的好处是，不管业务细节如何变化，日志的格式是固定的，这样能保证方案的通用性。

这个服务升级风险较小：

• 写接口是少数接口，改动点较少；
• 升级只是增加了一些日志，对业务功能没有任何影响；

步骤二：研发一个数据迁移工具，进行数据迁移。这个数据迁移工具和离线迁移工具一样，把旧库中的数据转移到新库中来。

这个小工具的风险较小：

• 整个过程依然是旧库对线上提供服务；
• 小工具的复杂度较低；
• 任何时间发现问题，都可以把新库中的数据干掉重来；
• 可以限速慢慢迁移，技术同学没有时间压力；

在数据迁移的过程中，旧库依然对线上提供着服务，库中的数据随时可能变化，这个变化并没有反映到新库中来，于是旧库和新库的数据并不一致，所以不能直接切库，需要将数据追平。

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

1. 读取日志，得到哪个库、哪个表、哪个主键发生了变化；
2. 把旧库中对应主键的记录读取出来；
3. 把新库中对应主键的记录替换掉；

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

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

• 整个过程依然是旧库对线上提供服务；
• 小工具的复杂度较低；
• 任何时间发现问题，大不了从步骤二开始重来；
• 可以限速慢慢重放日志，技术同学没有时间压力；

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

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

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

• 整个过程依然是旧库对线上提供服务；
• 小工具的复杂度较低；
• 任何时间发现问题，大不了从步骤二开始重来；
• 可以限速慢慢比对数据，技术同学没有时间压力；

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

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

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

1.3. 双写法

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

• 旧库与新库的同时insert；
• 旧库与新库的同时delete；
• 旧库与新库的同时update；

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

这个服务升级风险较小：

• 写接口是少数接口，改动点较少；
• 新库的写操作执行成功与否，对业务功能没有任何影响；

步骤二：研发一个数据迁移工具，进行数据迁移，把旧库中的数据转移到新库中来。

数据迁移完成之后，就能够切到新库提供服务了。因为前置步骤进行了双写，所以理论上数据迁移完之后，新库与旧库的数据应该完全一致。

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

如上图所示：

• 左侧是旧库中的数据，右侧是新库中的数据；
• 按照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。

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

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

步骤四：数据完全一致之后，将流量切到新库，完成平滑数据迁移。

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

2. 秒级扩容

前面我们已经介绍了数据迁移的方法，下面我们看一下在水平切分后另一种平滑扩容的方法。

为了保证数据库的高可用，我们一般采取DB的双主同步+keepalived+虚ip的高可用方案，方案架构图如下：

上图所示，两个相互同步的主库使用相同的虚ip。当主库挂掉的时候，虚ip自动漂移到另一个主库，整个过程对调用方透明，通过这种方式保证数据库的高可用。

下面以2个库扩为4个库为例进行分步骤讲解：

步骤一：修改配置。

主要修改两处：

数据库实例所在的机器做双虚ip：

• 原%2=0的库是虚ip0，现增加一个虚ip00；
• 原%2=1的库是虚ip1，现增加一个虚ip11；

修改服务的配置，将2个库的数据库配置，改为4个库的数据库配置，修改的时候要注意旧库与新库的映射关系：

• %2=0的库，会变为%4=0与%4=2；
• %2=1的部分，会变为%4=1与%4=3；

步骤二：reload配置，实例扩容

服务层reload配置，reload可能是这么几种方式：

• 比较原始的，重启服务，读新的配置文件；
• 高级一点的，配置中心给服务发信号，重读配置文件，重新初始化数据库连接池；

不管哪种方式，reload之后，数据库的实例扩容就完成了，原来是2个数据库实例提供服务，现在变为4个数据库实例提供服务，这个过程一般可以在秒级完成。

整个过程可以逐步重启，对服务的正确性和可用性完全没有影响：

• 即使%2寻库和%4寻库同时存在，也不影响数据的正确性，因为此时仍然是双主数据同步的；
• 即使%4=0与%4=2的寻库落到同一个数据库实例上，也不影响数据的正确性，因为此时仍然是双主数据同步的；

完成了实例的扩展，会发现每个数据库的数据量依然没有下降，所以第三个步骤还要做一些收尾工作。

步骤三：收尾工作，数据收缩

1. 把双虚ip修改回单虚ip；
2. 解除旧的双主同步，让成对库的数据不再同步增加；
3. 增加新的双主同步，保证高可用；
4. 删除掉冗余数据，例如：ip0里%4=2的数据全部删除，只为%4=0的数据提供服务。

3. 参考资料

《架构师训练营》

https://mp.weixin.qq.com/s/1ZswtROH32_SuaJxeg-vKw