内容摘要：最近有一套MySQL集群环境的服务器即将过保，为了避免后续带来的一些额外问题，需要提前考虑服务器的迁移计划，但是现在的线上业务，申请维护时间是比较困难的，而且在线变更的容忍时间是很短暂的，一般在业务层

最近有一套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服务，这样业务就又恢复成为和之前对等的使用模式。

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

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