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

news2024/11/26 18:37:15

文章目录

- 1 背景
- 2 迁移方案选择
- - 2.1 方案一：扩容+主从切换
  - 2.2 方案二：级联切换
  - 2.3 方案对比
- 3 如何又快又稳完成MySQL机房迁移
- - 3.1 提前搭建级联
  - 3.2 停服
  - 3.3 批量操作自动化，关键步骤解耦
  - 3.4 集群分级
  - 3.5 切换前、后置检查
  - 3.6 灰度切换验证
- 4 写在最后

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系统要求极高，就算是大厂自行维护的高可用系统，恐怕也难以保证在短时间内依靠高可用系统完成百余套集群的无损切换。
方案二：原理简单，切换速度快，单个集群切换时间<10s，对业务影响小。但需要大量自动化开发，例如自动扩容、自动搭建级联集群、自动前/后置检查、自动切换读/写流量等，开发成本高。

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

级联读流量切换示意图
级联写流量切换示意图

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

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

3.1 提前搭建级联

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

限制逻辑：

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

级联搭建过程：

3.2 停服

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