喝茶聊方案:分库分表方案之数据迁移

迁移方案概览

分库分表需要从单库迁移到分片库,这就涉及到迁移工作.那怎么迁移?看了下有这几种迁移方式

• 停机迁移
• 利用数据库主从同步迁移
• 开发写程序迁移

停机迁移

停机迁移简要说下,就是说提前准备一个流量少的时间点,提前发布好公告服务停机,然后把数据从单片库搬运到分片库后,再启动新的读写分片库的服务就完了.这里有几个缺点

• 需要运维,开发和测试都在场,协同成本比较高
• 影响用户使用
• 不做额外处理的话,为了保证数据完整,需要所有服务停机后再做数据搬运,数据较多的情况下数据搬运有一定时间消耗
• 如果读写分片服务的程序有问题,项目需要停服务回滚不说,新数据要还原回去,还要写程序从分片库同步回单片库.

其中比较要紧的是数据不方便还原.如果新数据有问题能立刻切回原数据就好了.

利用主从同步迁移

网上有方案说,成倍扩容,利用mysql主从同步来进行数据搬运.然后停服务切换.

双写程序迁移

双写就是说需要向单片库和分片库分别写一份数据,然后也需要找个流量少的时间点将流量切换到分片库, 这里涉及这几件事

双写(增量同步)

这里同步包括增量和全量同步

• 利用双写程序,进行增量同步数据,这里能保证insert的新增数据单库和分片库一致

历史数据迁移与比对(全量同步)

• 利用迁移程序进行全量迁移,将单库老数据迁移到分片数据库.

• 利用比较程序,发现全量迁移过程中单片库数据的变动:比较程序扫描单片库数据和分片库数据差异. 如果有差异需要以单片库为准,把数据同步到分片库. 扫描可以是全量+增量扫描
• 扫描发现的差异数据,利用迁移程序进行增量迁移,直到数据一致

切读流量

• 迁移完成后,比对程序可以定时跑一定时间内的数据,用于发现异常导致的数据不一致情况,经过一定时间比对无问题后,找个流量少的时间段,将开关切换为读写都为分片库,另外再双写单片库(保证可回滚)

下线双写

• 经过一段时间观察可以下线单库,注意下线相关无用代码.保证程序只读写分片库
• 注意原单库binlog程序迁移
• 下线双写相关代码

---

双写程序迁移细节

讲一下上面步骤中涉及的几个程序

• 双写程序
• 迁移程序
• 比较程序
• 切换开关

双写程序

双写可以通过aop实现,或者利用binlog同步来实现

迁移程序

• 多线程迁移
• 支持覆盖迁移(以单库为准)
• 支持指定迁移时间范围,支持指定订单号迁移
• 记录迁移过程中失败的单号(打印日志即可),支持失败单重新迁移
• 用的中间件方式迁移不支持批量insert,就只能单个insert.

比较程序注意

因为双写程序期间,原单库数据可能变动，所以需要有比较程序来发现不同。
比较程序注意

• 以单库为准，注意update变动外，也要注意delete变动，或者少迁移数据的情况。比如说同一单子，单库单子关联4件商品，但是分片库同步时候出问题，没有这个单子或单子没关关联任何商品，或单子只关联3件商品都是有问题的
• 注意数据库默认生成的日期，不能使用全等于，可以比较误差3秒内
• 字段过多导致比较慢可以只比较业务上会变动的数据。这个需要分析业务字段，需要对业务熟悉才可以

切换开关

可以参考以下来做热切换开关

单库,分片库读写开关
第一位标识读:单库读 0 分片库读 1
第二位标识写:单库写 0 单库分片库写 1 分片库写 2
比如:
默认:单库读,单库写 -> 0,0
上分片库双写:单库读 ,单库和分片库写-> 0,1
读流量切分片库:分片库读, 单库和分片库写 -> 1,1
下掉单库写:分片库读 ,分片库写 ->1,2

---

双写程序迁移优缺点

优点:
迁移流程由开发自己操控,可控性强.
发现不同步数据可以自行再次同步
不需要dba同时配合
缺点:
自行编码有开发和测试成本

最后

欢迎评论区留言拍砖/纠错/建议/提问/等等