数据平滑数据迁移
最后更新于：2022-04-02 04:12:41
[TOC]
> [参考](https://www.w3cschool.cn/architectroad/architectroad-data-smooth-migration.html)
## 问题的提出
面临的变更
1. 底层表结构变更
数据量非常大的情况下，数据表增加了一些属性，删除了一些属性，修改了一些属性
2. 分库个数变换
由于数据量的持续增加，底层分库个数非成倍增加。
3. 底层存储介质变换
底层存储引擎由一个数据库换为另一个数据库
## 方案
## 停机方案
1. 步骤一：挂一个类似“为了给广大用户提供更好的服务，服务器会在凌晨0:00-0:400进行停机维护”的公告，并在对应时段进行停机，这个时段系统没有流量进入。
2. 步骤二：停机后，研发一个离线的数据迁移工具，进行数据迁移。针对第一节的三类需求，会分别开发不同的数据迁移工具。
1. 底层表结构变更需求：开发旧表导新表的工具
2. 分库个数变换需求：开发2库导3库的工具
3. 底层存储介质变换需求：开发Mongo导Mysql工具
3. 步骤三：恢复服务，并将流量切到新库，不同的需求，可能会涉及不同服务升级。
1. 底层表结构变更需求：服务要升级到访问新表
2. 分库个数变换需求：服务不需要升级，只需要改寻库路由配置
3. 底层存储介质变换需求：服务升级到访问新的存储介质
### 平滑迁移-追日志法
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，等日志重放程序完全追上数据后，再进行切库切流量
### 平滑迁移-双写法
1. 步骤一：服务进行升级，对“对旧库上的数据修改”（这里的修改，为数据的insert, delete, update），在新库上进行相同的修改操作，这就是所谓的“双写”，主要修改操作包括：
1. 旧库与新库的同时insert
2. 旧库与新库的同时delete
3. 旧库与新库的同时update
由于新库中此时是没有数据的，所以双写旧库与新库中的affect rows可能不一样，不过这完全不影响业务功能，只要不切库，依然是旧库提供业务服务。
这个服务升级风险较小：
1. 写接口是少数接口，改动点较少
2. 新库的写操作执行成功与否，对业务功能没有任何影响
2. 步骤二：研发一个数据迁移工具，进行数据迁移。这个数据迁移工具在本文中已经出现第三次了，把旧库中的数据转移到新库中来。
这个小工具的风险较小：
1. 整个过程依然是旧库对线上提供服务
2. 小工具的复杂度较低
3. 任何时间发现问题，都可以把新库中的数据干掉重来
4. 可以限速慢慢迁移，技术同学没有时间压力
';