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

IT行业相对于一般传统行业，发展更新速度更快，一旦停止了学习，很快就会被行业所淘汰。所以我们需要踏踏实实的不断学习，精进自己的技术，尤其是初学者。今天golang学习网给大家整理了《天！转转MySQL机房迁移半小时结束战斗？》，聊聊MySQL、机房，我们一起来看看吧！

1 背景

作为国内领先的循环经济产业公司，随着转转业务的不断发展，基础服务设施已然到了“蜕壳”的阶段。

目前在用的IDC资源已趋于饱和，难以满足后续的发展需求。

同时，随着腾讯云提供的负载均衡技术迭代，需要将TGW（Tencent GateWay）替换为CLB（Cloud Load Balancer）。

经过运维同学近半年时间的筹划和建设，全新IDC和负载均衡技术（CLB）已完成升级建设并正式投产，MySQL、TiDB、Redis等公共基础服务需要有序进行迁移切换。对于MySQL迁移工作，面临集群数量多、操作影响大、操作要求高等一系列难题，需要充分调研现状并制定合理的方案，进一步降低对业务服务的感知。

2 迁移方案选择

2.1 方案一：扩容+主从切换

通过备份扩容出足够数量的从库，再依赖MHA（Master High Availability）系统发起主动切换，最终下线旧节点完成集群拓扑变更。

2.2 方案二：级联切换

通过备份搭建级联集群，完成新集群数据同步，再通过断级联+域名切换的方式完成集群变更。

2.3 方案对比

• 方案一：开发量小，扩容和MHA切换都比较容易实现。但单个集群MHA切换时间>30s，对业务的影响时间过长，且机房迁移要求具备大规模切换能力，这就对MHA系统要求极高，就算是大厂自行维护的高可用系统，恐怕也难以保证在短时间内依靠高可用系统完成百余套集群的无损切换。
• 方案二：原理简单，切换速度快，单个集群切换时间，对业务影响小。但需要大量自动化开发，例如自动扩容、自动搭建级联集群、自动前/后置检查、自动切换读/写流量等，开发成本高。

落地方案的选定，重点考虑对业务的影响，哪种方案又快又稳对业务感知又小就选哪种，毫无疑问，方案二胜出。级联方案还有一个明显优势，新集群搭建过程中可以平滑升级负载均衡（CLB替换TGW）

• 级联读流量切换示意图




• 级联写流量切换示意图

3 如何又快又稳完成MySQL机房迁移

MySQL集群迁移切换的风险非常大，稍加操作不当就可导致整套集群不可用，极端情况下可能直接让线上服务停摆。转转线上MySQL集群数量较多，如何又快又稳完成MySQL机房迁移工作？

3.1 提前搭建级联

通过备份扩容新集群，并与老集群建立级联关系，提前搭建好所有待迁移集群级联。由于转转采用单机多实例部署的架构，新建集群时得重点考虑混合部署带来的问题，需要提前整理各集群单实例磁盘、内存占用数据。在开发自动搭建级联集群脚本时，需要同时兼顾机器负载均衡和资源成本。

限制逻辑：

• 单机主库实例不超过5个
• 单机从库实例不超过10个
• 单机总实例不超过15个
• 单机内存、磁盘使用率不超过85%

级联搭建过程：

3.2 停服

核心集群间的上下游关系错综复杂，尤其是交易库和商品库。如果停写一套集群，其他好几套关联集群也会受影响。另外，尽管当前部分业务方具备双写能力，能够应对切换停写带来的影响，但集群数量太多，并非所有业务都有足够人力成本投入额外开发。综合考虑，与其花费大量人工成本去梳理上下游关系和额外开发，不如在凌晨低峰期短暂停服，批量切换核心集群。这项决定意味着我们需要具备过硬的批量操作和恢复能力，务必将操作时间进一步缩短，给测试、开发留足验证时间，尽量减少停服时长。

3.3 批量操作自动化，关键步骤解耦

整个迁移周期内存在大量操作，需要降低人工误操作风险，同时对操作时间也有一定要求，因此，所有操作都需要实现自动化。对于关键步骤应当解耦处理，自动化模块需要能够独立运行，所有模块相互间形成闭环，当切换存在问题时能快速定位故障发生位置，及时回滚。在闭环中实现：

• 搭建级联集群自动化
• 前/后置检查自动化
• 批量切读
• 批量切写
• 自动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切换过程中能够反馈线上大部分集群可能遇到的问题。采用灰度切换验证，摸着石头过河，把意料之外的浑水都淌一遍，不断迭代自动化脚本。

灰度切换顺序：

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

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

• 多域名问题

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

• cmdb信息不准确

部分老集群元数据长时间未维护，实例信息、域名指向信息可能有误。在迁移切换前，需要花精力去校对最新数据

4 写在最后

转转线上MySQL集群规模400+，需要在9月27日凌晨停服期间完成所有集群切换。P3、P2集群在停服前已完成批量切换，剩余P1核心集群累计100+，平均耗时10s/套，半小时内结束战斗。停服期间因前期已规避大部分问题，切换过程非常流畅，后续的验证、压测也均符合预期。

关于作者

黄建波，转转DBA。主要负责转转MySQL运维及数据库平台开发。

好了，本文到此结束，带大家了解了《天！转转MySQL机房迁移半小时结束战斗？》，希望本文对你有所帮助！关注golang学习网公众号，给大家分享更多数据库知识！