mysql 缩容_MySQL分布式架构扩缩容的初步设计

本文探讨了MySQL分布式架构的缩容问题,提出了一种思路。在4个物理分片,每个包含4个逻辑分片的架构下,讨论了如何从4个缩至2个物理分片的平滑过程,重点关注数据的迁移与合并,确保在缩容过程中保持数据一致性。
摘要由CSDN通过智能技术生成

这是学习笔记的第1821篇文章

MySQL分布式架构的扩缩容是一个很有意思的话题。严格的说,我们所说的这种架构方案是一种伪分布式架构,我们就做下统称。重点是扩缩容的思路上。

如果一套环境的主从完整,分为多个逻辑分片的情况下,大体是这样的架构。

这个架构采用了4个物理分片,每个物理分片上有4个逻辑分片,总共有16个逻辑分片,也就意味着一张表被分为了16份。

e3eb2117bba462d4d6dd9be5617bb340.png

对于扩容来说,是优先考虑主库写入为主,所以我们的扩容可以是2N的规模来扩容,比如4个物理分片,可以扩容为8个物理分片,大体的架构和分布如下,这个时候从库顶上来做了主库。

9ab8444757effc833bb88c130c07682c.png

从扩容的角度来说,这也就是我们预期要做的事情,4个变8个,8个变16个。一套环境按照设定的分片规模可以扩容两次。

而缩容怎么来做呢,我们需要考虑得更细致一些,所以我就截取了物理分片1的一个相对详细的数据复制关系图。

扩容前,分片节点上的4个逻辑分片都是active状态,都可以写入数据,从库是inactive,只负责数据同步。

11f1153d4a2ed3ebe64825d203319d56.png

扩容后,原本的db1,db2为active状态,而db3,db4在原来的Slave节点上是active状态

c0af6d6a6604a676e306967aaa251e42.png这个基础上,我们需要保证的就是将原本隔离的节点数据统一为Master端active状态。这个过程说起来容易,操作起来就是一个难点了。

11f1153d4a2ed3ebe64825d203319d56.png

这个事情如果相对平滑的完成,其实整个分布式集群的管理就不在话下了。

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值