MySQL中间件集群平滑迁移的初步方案

数据库 MySQL
整个集群的迁移计划是按照1:1的模式进行服务器对等替换,也就意味着原来有30个服务器,要对等30个服务器来进行平移,按照之前的实践来看,整体的迁移时间基本控制字5秒以内。

[[385624]]

最近有一套MySQL集群环境的服务器即将过保,为了避免后续带来的一些额外问题,需要提前考虑服务器的迁移计划,但是现在的线上业务,申请维护时间是比较困难的,而且在线变更的容忍时间是很短暂的,一般在业务层也有容错机制,比如超时时间,容错次数等,所以希望整个方案是可控并且变更时间对于业务侧是清晰的。

整个集群的迁移计划是按照1:1的模式进行服务器对等替换,也就意味着原来有30个服务器,要对等30个服务器来进行平移,按照之前的实践来看,整体的迁移时间基本控制字5秒以内。

集群的整体部署架构如下,连接层使用了基于Consul的负载均衡机制,数据分片节点使用了一主一从的模式。

在迁移中,因为从库默认是不接入业务的,所以相应的从库的替换可以平滑实现,即用新的服务器顶上去成为新的从库,如果可以保证IP不变,整体的拓扑结构是没有任何变化的。

接下来,考虑的是要新增一个数据从库节点,这个节点是基于新的从库节点进行的级联复制,整体结构如下:

在迁移前,需要对已有的中间件进行缩容,先能够逐步减少为1个中间件节点,这个过程可以使用备用连接池技术实现,也可以主动触发应用重连机制实现。

在切换的过程中,可以把原本的Consul模式降级为基于IP的模式,中间件P1连接的数据分片节点会在切换中可以先映射为S1-S4,这个过程简单理解就是重启中间件节点P1,在重启的过程中会逐步释放M1-M4上面的连接,为了保证数据的一致性,需要配置M1-S1,M2-S2,M3-S3,M4-S4之间的数据双向复制。

切换完成后就成为简单的一主一从的拓扑结构,整体来说还是比较好理解的,这样就整合到了新的服务器组中。

增加中间件节点,并且开启Consul服务,这样业务就又恢复成为和之前对等的使用模式。

当然整个过程中都是最简化的步骤,在每个步骤中都需要有严谨的思考和验证。

本文转载自微信公众号「杨建荣的学习笔记」,可以通过以下二维码关注。转载本文请联系杨建荣的学习笔记公众号。

 

责任编辑:武晓燕 来源: 杨建荣的学习笔记
相关推荐

2020-02-10 15:30:51

数据库MySQLDAL

2019-09-29 11:04:22

MySQL数据库Atlas

2016-11-11 21:00:46

中间件

2011-05-24 15:10:48

2021-02-11 08:21:02

中间件开发CRUD

2011-08-10 13:03:58

CJDBC数据库集群

2022-05-10 09:24:44

中间件应用方案

2015-02-07 21:52:45

PaaS中间件

2018-07-29 12:27:30

云中间件云计算API

2018-02-01 10:19:22

中间件服务器系统

2018-05-02 16:23:24

中间件RPC容器

2013-03-13 10:37:22

中间件Windows

2021-06-15 10:01:02

应用系统软件

2022-11-18 07:54:02

Go中间件项目

2012-11-30 10:21:46

移动中间件

2023-06-29 10:10:06

Rocket MQ消息中间件

2023-10-24 07:50:18

消息中间件MQ

2009-06-16 15:55:06

JBoss企业中间件

2012-09-13 15:48:16

云计算中间件

2017-05-23 18:55:05

mysql-proxy数据库架构
点赞
收藏

51CTO技术栈公众号