转转MySQL机房迁移半小时结束战斗？( 二 )

2026-01-12 mysql

搭建级联集群自动化
前/后置检查自动化
批量切读
批量切写
自动kill旧集群连接，检测切换后新集群连接
批量下线旧集群

3.4 集群分级我们将线上集群分为3个等级，由高到低依次为P1、P2、P3，各等级占比约为1:1:1

P3集群可在白天任意时间切换
P2集群可在晚上8点-10点操作
P1集群需要在凌晨停服期间操作

我们正不断推进和完善集群服务分级管理，对于达到一定规模符合等级要求的集群，我们将投入更多精力、提供更多的资源去支撑高等级集群的可靠性及性能。
3.5 切换前、后置检查整个切换周期内，新、老集群的前、后置检查必不可少。切换前后配置不一致可能引发故障，尤其是一些关键参数配置。
前置检查：

新集群vip-rshost链路连通性
buffer_pool_size
sql_mode
从节点个数
级联延迟
...

后置检查：

新、老主read_only状态
新、老集群业务实时连接
域名切换后是否指向新集群
...

3.6 灰度切换验证完成各项自动化代码开发后，先通过测试集群进行多轮批量切换验证，随后按照集群等级开始线上集群切换。对于P3集群，由于切换操作对业务的影响较小，但又不同于测试集群，P3切换过程中能够反馈线上大部分集群可能遇到的问题。采用灰度切换验证，摸着石头过河，把意料之外的浑水都淌一遍，不断迭代自动化脚本。
灰度切换顺序：

单套切换
小批量切换（<10）
大批量切换（>30）

灰度切换验证期间遇到的问题：

多域名问题

按标准化运维，同一集群同一角色有且仅有一个域名，但线上集群存在一套集群使用多个主库、从库域名的情况。在流量切换时，需要兼容处理多域名问题

cmdb信息不准确

部分老集群元数据长时间未维护，实例信息、域名指向信息可能有误。在迁移切换前，需要花精力去校对最新数据
4 写在最后转转线上MySQL集群规模400+，需要在9月27日凌晨停服期间完成所有集群切换。P3、P2集群在停服前已完成批量切换，剩余P1核心集群累计100+，平均耗时10s/套，半小时内结束战斗。停服期间因前期已规避大部分问题，切换过程非常流畅，后续的验证、压测也均符合预期。
【转转MySQL机房迁移半小时结束战斗？】

转转MySQL机房迁移半小时结束战斗？

文章插图

推荐阅读

上一篇：苹果手机远程控制安卓手机，为什么不能发起控制？

下一篇：浅析MySQL的Table_cache实现