最近有一套MySQL集群环境的服务器即将到期。为了避免以后出现一些额外的问题，需要提前考虑服务器的迁移计划，但是目前线上的业务，应用维护时间比较困难，对线上变更的容忍时间很短。一般在业务层都有容错机制，比如超时时间，容错次数等，所以希望整个方案是可控的，变更时间对业务方来说是明确的。整个集群的迁移计划是1:1替换服务器，也就是说原来有30台服务器，需要迁移30台服务器。按照之前的做法，整体迁移时间基本控制字在5秒以内。集群的整体部署架构如下。连接层采用基于Consul的负载均衡机制，数据分片节点采用主从模型。在迁移过程中，由于从库默认不访问业务，所以可以顺利实现对应从库的更换，即使用新的服务器成为新的从库。如果能保证IP不变，则整体拓扑结构没有变化。接下来考虑增加一个数据从节点，也就是基于新的从节点进行级联复制。整体结构如下：在迁移之前，需要对已有的中间件进行缩容。可以逐渐缩减为一个中间件节点。这个过程可以使用备用连接池技术来实现，也可以通过主动触发应用重连机制来实现。在切换过程中，可以将原来的Consul模式降级为IP-based模式。连接到中间件P1的数据分片节点在切换时会优先映射到S1-S4。这个过程简单理解就是重启中间件节点P1，在重启过程中，M1-M4上的连接会逐渐释放。为了保证数据的一致性，需要配置M1-S1、M2-S2、M3-S3、M4-S4之间的双向数据复制。切换完成后就变成了简单的一主一从拓扑，整体上还是比较容易理解的，所以集成到新的服务器组中。添加中间件节点，启动Consul服务，这样业务就会恢复到之前一样的使用模式。当然，整个过程是最简化的一步，每一步都需要严谨的思考和验证。本文转载自微信公众号《杨建荣的学习笔记》，可通过以下二维码关注。转载本文请联系杨建荣学习笔记公众号。
