喝茶聊方案:分库分表方案之数据迁移
- - 掘金 架构分库分表需要从单库迁移到分片库,这就涉及到迁移工作.那怎么迁移?看了下有这几种迁移方式. 停机迁移简要说下,就是说提前准备一个流量少的时间点,提前发布好公告服务停机,然后把数据从单片库搬运到分片库后,再启动新的读写分片库的服务就完了.这里有几个缺点. 需要运维,开发和测试都在场,协同成本比较高. 不做额外处理的话,为了保证数据完整,需要所有服务停机后再做数据搬运,数据较多的情况下数据搬运有一定时间消耗.
分库分表需要从单库迁移到分片库,这就涉及到迁移工作.那怎么迁移?看了下有这几种迁移方式
停机迁移简要说下,就是说提前准备一个流量少的时间点,提前发布好公告服务停机,然后把数据从单片库搬运到分片库后,再启动新的读写分片库的服务就完了.这里有几个缺点
其中比较要紧的是数据不方便还原.如果新数据有问题能立刻切回原数据就好了.
网上有方案说,成倍扩容,利用mysql主从同步来进行数据搬运.然后停服务切换.
双写就是说需要向单片库和分片库分别写一份数据,然后也需要找个流量少的时间点将流量切换到分片库, 这里涉及这几件事
这里同步包括增量和全量同步
讲一下上面步骤中涉及的几个程序
双写可以通过aop实现,或者利用binlog同步来实现
因为双写程序期间,原单库数据可能变动,所以需要有比较程序来发现不同。
比较程序注意
可以参考以下来做热切换开关
单库,分片库读写开关
第一位标识读:单库读 0 分片库读 1
第二位标识写:单库写 0 单库分片库写 1 分片库写 2
比如:
默认:单库读,单库写 -> 0,0
上分片库双写:单库读 ,单库和分片库写-> 0,1
读流量切分片库:分片库读, 单库和分片库写 -> 1,1
下掉单库写:分片库读 ,分片库写 ->1,2
优点:
迁移流程由开发自己操控,可控性强.
发现不同步数据可以自行再次同步
不需要dba同时配合
缺点:
自行编码有开发和测试成本
欢迎评论区留言拍砖/纠错/建议/提问/等等