[TOC] > [参考](https://www.w3cschool.cn/architectroad/architectroad-data-smooth-migration.html) ## 问题的提出 ![UTOOLS1577186355151.png](http://yanxuan.nosdn.127.net/f8410fbdd6b45017d8ee5bd897e3db96.png) 面临的变更 1. 底层表结构变更 ![UTOOLS1577186406678.png](http://yanxuan.nosdn.127.net/59008b71a84925387b14e323f56bf258.png) 数据量非常大的情况下,数据表增加了一些属性,删除了一些属性,修改了一些属性 2. 分库个数变换 ![UTOOLS1577186459569.png](http://yanxuan.nosdn.127.net/db05be42993c0ecb4355f5d63bcf2864.png) 由于数据量的持续增加,底层分库个数非成倍增加。 3. 底层存储介质变换 ![UTOOLS1577186511460.png](http://yanxuan.nosdn.127.net/4ecbd8d7c75b7dec682aedb3f1fd2de2.png) 底层存储引擎由一个数据库换为另一个数据库 ## 方案 ## 停机方案 1. 步骤一:挂一个类似“为了给广大用户提供更好的服务,服务器会在凌晨0:00-0:400进行停机维护”的公告,并在对应时段进行停机,这个时段系统没有流量进入。 2. 步骤二:停机后,研发一个离线的数据迁移工具,进行数据迁移。针对第一节的三类需求,会分别开发不同的数据迁移工具。 1. 底层表结构变更需求:开发旧表导新表的工具 2. 分库个数变换需求:开发2库导3库的工具 3. 底层存储介质变换需求:开发Mongo导Mysql工具 3. 步骤三:恢复服务,并将流量切到新库,不同的需求,可能会涉及不同服务升级。 1. 底层表结构变更需求:服务要升级到访问新表 2. 分库个数变换需求:服务不需要升级,只需要改寻库路由配置 3. 底层存储介质变换需求:服务升级到访问新的存储介质 ### 平滑迁移-追日志法 ![UTOOLS1577187368614.png](http://yanxuan.nosdn.127.net/73cf0aaea35dcd1d1ccf1e26d6a043cf.png) 1. 步骤一:服务进行升级,记录“对旧库上的数据修改”的日志(这里的修改,为数据的insert, delete, update),这个日志不需要记录详细数据,主要记录: 1. 被修改的库 2. 被修改的表 3. 被修改的唯一主键 具体新增了什么行,修改后的数据格式是什么,不需要详细记录。这样的好处是,不管业务细节如何变化,日志的格式是固定的,这样能保证方案的通用性 2. 步骤二:研发一个数据迁移工具,进行数据迁移。这个数据迁移工具和离线迁移工具一样,把旧库中的数据转移到新库中来。 这个小工具的风险较小: 1. 整个过程依然是旧库对线上提供服务 2. 小工具的复杂度较低 3. 任何时间发现问题,都可以把新库中的数据干掉重来 3. 可以限速慢慢迁移,技术同学没有时间压力 在数据迁移的过程中,旧库依然对线上提供着服务,库中的数据随时可能变化,这个变化并没有反映到新库中来,于是旧库和新库的数据并不一致,所以不能直接切库,需要将数据追平 3. 步骤三:研发一个读取日志并迁移数据的小工具,要把步骤二迁移数据过程中产生的差异数据追平。这个小工具需要做的是: 1. 读取日志,得到哪个库、哪个表、哪个主键发生了变化 2. 把旧库中对应主键的记录读取出来 3. 把新库中对应主键的记录替换掉 无论如何,**原则是数据以旧库为准** 这个小工具的风险也很小: 1. 整个过程依然是旧库对线上提供服务 2. 小工具的复杂度较低 3. 任何时间发现问题,大不了从步骤二开始重来 4. 可以限速慢慢重放日志,技术同学没有时间压力 新库与旧库中的数据追平也会是一个“**无限逼近”**的过程 4. 步骤四:在持续重放日志,追平数据的过程中,研发一个数据校验的小工具,将旧库和新库中的数据进行比对,直到数据完全一致。 这个小工具的风险依旧很小: 1. 整个过程依然是旧库对线上提供服务 2. 小工具的复杂度较低 3. 任何时间发现问题,大不了从步骤二开始重来 4. 可以限速慢慢比对数据,技术同学没有时间压力 5. 步骤五:在数据比对完全一致之后,将流量迁移到新库,新库提供服务,完成迁移。 如果步骤四数据一直是99.9%的一致,不能完全一致,也是正常的,可以做一个秒级的旧库readonly,等日志重放程序完全追上数据后,再进行切库切流量 ### 平滑迁移-双写法 ![UTOOLS1577187928361.png](http://yanxuan.nosdn.127.net/6a095131e50a2b3e2e5d5757493c0588.png) 1. 步骤一:服务进行升级,对“对旧库上的数据修改”(这里的修改,为数据的insert, delete, update),在新库上进行相同的修改操作,这就是所谓的“双写”,主要修改操作包括: 1. 旧库与新库的同时insert 2. 旧库与新库的同时delete 3. 旧库与新库的同时update 由于新库中此时是没有数据的,所以双写旧库与新库中的affect rows可能不一样,不过这完全不影响业务功能,只要不切库,依然是旧库提供业务服务。 这个服务升级风险较小: 1. 写接口是少数接口,改动点较少 2. 新库的写操作执行成功与否,对业务功能没有任何影响 2. 步骤二:研发一个数据迁移工具,进行数据迁移。这个数据迁移工具在本文中已经出现第三次了,把旧库中的数据转移到新库中来。 这个小工具的风险较小: 1. 整个过程依然是旧库对线上提供服务 2. 小工具的复杂度较低 3. 任何时间发现问题,都可以把新库中的数据干掉重来 4. 可以限速慢慢迁移,技术同学没有时间压力