分库分表后,如何不停机迁移数据?

前文我们讲了如何分库分表,现在假设我们已经做好了分库分表,把原来的单库单表的设计改造成了多库多表结构,那么如何进行数据迁移呢?

一般会有这几种方案:

  • 停机迁移方案

  • 双写迁移方案

停机迁移方案

这种方案最简单也是最low的。

数据迁移前,在网站或者app挂个公告,说0点到早上6点系统进行维护,无法访问。

接着到0点停机,系统停掉,就没有流量写入了,此时老的单库单表就不会有新数据写入了。然后你用提前写好迁移数据的工具,将单库单表的数据哗哗哗读出来,写到分库分表里面去。

迁移完了之后,修改系统的数据库连接配置啥的,包括可能代码和SQL也许有修改,那你就用最新的代码,然后直接启动连到新的分库分表上去。

这些工作做完之后,验证一下系统,如果没什么问题, 整个迁移工作就结束了,还是画个示意图让大家更有感觉写。

图片

图片

图1 基于sharding-shpere迁移数据

图片

图片

图2 基于mycat迁移数据

停机迁移数据,其主要缺点是必须停机几个小时,而且如果一旦迁移没成功,必须切回原来的单库单表方案,下次还得发公告再次停机迁移数据。

有的项目一旦上线就不能停止运行,那么上面的方案就无法实行了。而且现在比较主流的迁移方案是不停机双写迁移方案。所以下面我们介绍下双写迁移方案,在不停机的情况完成系统的无缝切换。

双写迁移方案

简单来说,就是在线上系统里面,之前所有对数据库增删改的操作,除了对老库增删改,都加上对新库的增删改,这就是所谓的双写。

然后新系统部署上线后,用数据迁移工具,读老库数据写到新库。如果读出来的数据在新库里没有,或者这条数据的update_time最后修改的时间,比新库的数据新才会写。简单来说,就是不允许用老数据覆盖新数据。

导完一轮之后,有可能数据还是存在不一致,那么就程序自动做一轮校验,对比新老库每个表的每条数据,如果有不一样的,就针对那些不一样的,从老库读数据再次写。反复循环,直到两个库每个表的数据都完全一致为止。

接着当数据完全一致了,就 ok 了,基于仅仅使用分库分表的最新代码,重新部署一次,不就仅仅基于分库分表在操作了么。所以现在基本玩儿数据迁移之类的,都是这么干的。

图片

图片

图3 双写不停机迁移数据方案

双写不停机迁移数据方案,能无缝的升级系统,但要注意数据的准确性,必须做好数据的验证,不能用旧数据覆盖新数据。

END

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
分库分表是一种常用的数据库分布式架构设计方法,可以提高数据库的横向扩展性和性能。然而,分库分表也会面临一些问题,包括: 1. 数据一致性:由于数据被拆分到不同的数据库或表中,跨节点的事务管理和数据一致性变得更加困难。需要考虑如何处理分布式事务和跨节点的数据同步。 2. 跨节点查询:在分库分表环境下,跨节点的查询需要在多个数据库或表中执行,并且需要合并和处理查询结果。这可能会导致查询性能下降和复杂的查询逻辑。 3. 数据迁移和维护:当需要扩容或缩减数据库节点时,需要进行数据迁移和重新分片的操作,这可能会导致系统停机时间和数据迁移的复杂性增加。 4. 跨节点事务管理:在跨多个数据库或表的事务中,需要考虑如何保证事务的隔离性、一致性和持久性。这可能需要使用分布式事务管理机制或者重新设计业务逻辑。 5. 数据倾斜:由于数据分布不均匀或者某些热点数据的访问频率较高,可能导致某些数据库或表的负载过大,而其他节点负载较轻。需要采取合适的负载均衡策略来解决数据倾斜问题。 6. 跨节点索引和优化:在分库分表环境下,索引的设计和优化需要考虑跨节点查询的效率。需要根据实际业务场景和查询需求来选择合适的索引策略和优化方法。 以上是一些常见的问题,分库分表的实施需要综合考虑业务需求、系统性能和数据一致性等方面的因素,合理设计和规划才能发挥其优势。

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值