平台运行中，数据库如何平滑升级

1、问题的提出

互联网有不少“数据量较大，并发量较大，业务复杂度较高”的业务场景，其典型系统分层架构以下：

（1）上游是业务层biz，实现个性化的业务逻辑

（2）中游是服务层service，封装数据访问

（3）下游是数据层db，存储固化的业务数据

 

服务化分层架构的好处是，服务层屏蔽下游数据层的复杂性，例如缓存、分库分表、存储引擎等存储细节不须要向调用方暴露，而只向上游提供方便的RPC访问接口，当有一些数据层变化的时候，全部的调用方也不须要升级，只须要服务层升级便可。

 

互联网架构，不少时候面临着这样一些需求：

需求1->底层表结构变动：数据量很是大的状况下，数据表增长了一些属性，删除了一些属性，修改了一些属性。

 

需求2->分库个数变换：因为数据量的持续增长，底层分库个数非成倍增长。

 

需求3->底层存储介质变换：底层存储引擎由一个数据库换为另外一个数据库。

 

种种需求，都须要进行数据迁移，如何平滑迁移数据，迁移过程不停机，保证系统持续服务，是文本将要讨论的问题。

 

2、停机方案

在讨论平滑迁移数据方案以前，先看下不平滑的停机数据迁移方案，主要分三个步骤。

步骤一：挂一个相似“为了给广大用户提供更好的服务，服务器会在凌晨0:00-0:400进行停机维护”的公告，并在对应时段进行停机，这个时段系统没有流量进入。

 

步骤二：停机后，研发一个离线的数据迁移工具，进行数据迁移。针对第一节的三类需求，会分别开发不一样的数据迁移工具。

（1）底层表结构变动需求：开发旧表导新表的工具

（2）分库个数变换需求：开发2库导3库的工具

（3）底层存储介质变换需求：开发Mongo导Mysql工具

 

步骤三：恢复服务，并将流量切到新库，不一样的需求，可能会涉及不一样服务升级。

（1）底层表结构变动需求：服务要升级到访问新表

（2）分库个数变换需求：服务不须要升级，只须要改寻库路由配置

（3）底层存储介质变换需求：服务升级到访问新的存储介质

 

总的来讲，停机方案是相对直观和简单的，但对服务的可用性有影响，许多游戏公司的服务器升级，游戏分区与合区，可能会采用相似的方案。

 

除了影响服务的可用性，这个方案还有一个缺点，就是必须在指定时间完成升级，这个对研发、测试、运维同窗来讲，压力会很是大，一旦出现问题例如数据不一致，必须在规定时间内解决，不然只能回滚。根据经验，人压力越大越容易出错，这个缺点必定程度上是致命的。

 

不管如何，停机方案并非今天要讨论的重点，接下来看一下常见的平滑数据迁移方案。

 

3、平滑迁移-追日志法

平滑迁移方案一，追日志法，这个方案主要分为五个步骤。

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

 

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

（1）被修改的库

（2）被修改的表

（3）被修改的惟一主键

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

 

这个服务升级风险较小：

（1）写接口是少数接口，改动点较少

（2）升级只是增长了一些日志，对业务功能没有任何影响

 

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

 

这个小工具的风险较小：

（1）整个过程依然是旧库对线上提供服务

（2）小工具的复杂度较低

（3）任什么时候间发现问题，均可以把新库中的数据干掉重来

（4）能够限速慢慢迁移，技术同窗没有时间压力

 

数据迁移完成以后，就可以切到新库提供服务了么？

答案是否认的，在数据迁移的过程当中，旧库依然对线上提供着服务，库中的数据随时可能变化，这个变化并无反映到新库中来，因而旧库和新库的数据并不一致，因此不能直接切库，须要将数据追平。

 

哪些数据发生了变化呢？

步骤一中日志里记录的不就是么？

 

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

（1）读取日志，获得哪一个库、哪一个表、哪一个主键发生了变化

（2）把旧库中对应主键的记录读取出来

（3）把新库中对应主键的记录替换掉

不管如何，原则是数据以旧库为准。

 

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

（1）整个过程依然是旧库对线上提供服务

（2）小工具的复杂度较低

（3）任什么时候间发现问题，大不了从步骤二开始重来

（4）能够限速慢慢重放日志，技术同窗没有时间压力

 

日志重放以后，就可以切到新库提供服务了么？

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

 

何时数据会彻底一致呢？

 

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

 

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

（1）整个过程依然是旧库对线上提供服务

（2）小工具的复杂度较低

（3）任什么时候间发现问题，大不了从步骤二开始重来

（4）能够限速慢慢比对数据，技术同窗没有时间压力

 

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

 

若是步骤四数据一直是99.9%的一致，不能彻底一致，也是正常的，能够作一个秒级的旧库readonly，等日志重放程序彻底追上数据后，再进行切库切流量。

 

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

 

4、平滑迁移-双写法

平滑迁移方案二，双写法，这个方案主要分为四个步骤。

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

 

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

（1）旧库与新库的同时insert

（2）旧库与新库的同时delete

（3）旧库与新库的同时update

因为新库中此时是没有数据的，因此双写旧库与新库中的affect rows可能不同，不过这彻底不影响业务功能，只要不切库，依然是旧库提供业务服务。

 

这个服务升级风险较小：

（1）写接口是少数接口，改动点较少

（2）新库的写操做执行成功与否，对业务功能没有任何影响

 

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

 

这个小工具的风险较小：

（1）整个过程依然是旧库对线上提供服务

（2）小工具的复杂度较低

（3）任什么时候间发现问题，均可以把新库中的数据干掉重来

（4）能够限速慢慢迁移，技术同窗没有时间压力

 

数据迁移完成以后，就可以切到新库提供服务了么？

答案是确定的，由于前置步骤进行了双写，因此理论上数据迁移完以后，新库与旧库的数据应该彻底一致。

 

因为迁移数据的过程当中，旧库新库双写操做在同时进行，怎么证实数据迁移完成以后数据就彻底一致了呢？

 

如上图所示：

（1）左侧是旧库中的数据，右侧是新库中的数据

（2）按照primary key从min到max的顺序，分段，限速进行数据的迁移，假设已经迁移到now这个数据段

 

数据迁移过程当中的修改操做分别讨论：

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

（2）假设迁移过程当中进行了一个双delete操做，这又分为两种状况

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

         （2.2）假设这delete的数据属于[now,max]范围，即未完成迁移，则旧库中删除操做的affect rows为1，新库中删除操做的affect rows为0，可是数据迁移工具在后续数据迁移中，并不会将这条旧库中被删除的数据迁移到新库中，因此数据一致性仍没有被破坏

（3）假设迁移过程当中进行了一个双update操做，能够认为update操做是一个delete加一个insert操做的复合操做，因此数据仍然是一致的

 

除非除非除非，在一种很是很是很是极限的状况下：

（1）date-migrate-tool恰好从旧库中将某一条数据X取出

（2）在X插入到新库中以前，旧库与新库中恰好对X进行了双delete操做

（3）date-migrate-tool再将X插入到新库中

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

 

但不管如何，为了保证数据的一致性，切库以前，仍是须要进行数据校验的。

 

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

 

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

（1）整个过程依然是旧库对线上提供服务

（2）小工具的复杂度较低

（3）任什么时候间发现问题，大不了从步骤二开始重来

（4）能够限速慢慢比对数据，技术同窗没有时间压力

 

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

 

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

 

5、总结

针对互联网不少“数据量较大，并发量较大，业务复杂度较高”的业务场景，在

（1）底层表结构变动

（2）分库个数变换

（3）底层存储介质变换

的众多需求下，须要进行数据迁移，完成“平滑迁移数据，迁移过程不停机，保证系统持续服务”有两种常见的解决方案。

 

追日志法，五个步骤：

（1）服务进行升级，记录“对旧库上的数据修改”的日志

（2）研发一个数据迁移小工具，进行数据迁移

（3）研发一个读取日志小工具，追平数据差别

（4）研发一个数据比对小工具，校验数据一致性

（5）流量切到新库，完成平滑迁移

 

双写法，四个步骤：

（1）服务进行升级，记录“对旧库上的数据修改”进行新库的双写

（2）研发一个数据迁移小工具，进行数据迁移

（3）研发一个数据比对小工具，校验数据一致性

（4）流量切到新库，完成平滑迁移