分表数据迁移——渐进式双写不停机更新

最近需要一个方案，一开始要求做分表扩容，从2020年扩容到29年。
后面不知道为啥开始挤牙膏，要求：
1、方案包含表数据迁移
2、包含分表设计
3、包含不停机平滑更新方案
4、更新不允许修改旧库结构及数据，不影响业务本身
…就不能一次说完么

前言

分表方案已经给出，连接在此 分表

SQL数据迁移

将user_name 赋值给 user_id：

UPDATE accounts SET accounts.user_id = accounts.user_name；

将 user_name、relation_id 赋值为””：

UPDATE accounts SET accounts.user_name = “”,accounts.relation_id =
“”;

迁移至对应表：

INSERT INTO accounts_xxxx SELECT * FROM accounts AS t0 where
t0.user_id like “%xxxx%” ;

例如：

INSERT INTO accounts_202001 SELECT * FROM accounts AS t0 where
t0.user_id like “%202001%” OR t0.user_id like “%202002%” OR t0.user_id
like “%202003%” OR t0.user_id like “%202004%” OR t0.user_id like
“%202005%” OR t0.user_id like “%202006%” ;

渐进式双写不停机更新

示意图

文字步骤：

1. 按照“方案：分表”建立新库。同时检查初始环境配置，减少因环境导致的后续操作失误概率。
2. 使用“方案：数据迁移”迁移旧数据到新库，期间新库的增量、存量更新暂不处理。
3. 逐步切换所有应用到“双写”，额外将数据写入到新库，观察写入情况，确认写入稳定且符合相关条件继续推进。
4. 校正“步骤2”期间增量、存量更新的数据差异，同时观察新旧库写入情况，稳定且符合相关条件继续推进。
5. 切换读库到新库，观察新库读、写情况，情况大概持续一周，保证业务正常继续往后推进。
6. 取消旧库写入，关闭热配，完成上线。
7. 结束，清理废弃代码和数据。

注意事项

1. 读写切换，应逐步操作，防止修改热配导致的全部应用停机。
2. 读写切换前准备回滚方案，优先保证回滚可用。
3. 主库读写，从旧库切换到新库需要经过一段时间的观察，确认切换稳定后继续推进，避免出现不同阶段问题延迟出现导致的混乱。
4. 数据迁移尽量选择在低业务流量时间段操作，并降低迁移所需时间，方便减少后续数据校正所带来的开销。

最后

渐进式双写不停机方案，只是一个思路，没有实际实施测试。
PS：笔者根本不了解项目，偏偏老大让我写方案（吐血），还说实施的时候让项目负责的同时按照方案做更新就好了。我…，不得已，只能写思路。
读写切换、表结构转变、数据校正、数据观察什么的，都需要业务侧以及项目侧相关的信息，而笔者…不知道（别问我为啥不问，三言两语说不清，哭~）。
但是方案本身风险是很低的，阶段式更新，风险平滑，支持随时回滚。