作为国内领先的循环经济产业公司，随着转转业务的不断发展，基础服务设施已然到了“蜕壳”的阶段。
目前在用的IDC资源已趋于饱和，难以满足后续的发展需求。
同时，随着腾讯云提供的负载均衡技术迭代，需要将TGW（Tencent GateWay）替换为CLB（Cloud Load Balancer）。
经过运维同学近半年时间的筹划和建设，全新IDC和负载均衡技术（CLB）已完成升级建设并正式投产，MySQL、TiDB、redis等公共基础服务需要有序进行迁移切换。对于MySQL迁移工作，面临集群数量多、操作影响大、操作要求高等一系列难题，需要充分调研现状并制定合理的方案，进一步降低对业务服务的感知。
通过备份扩容出足够数量的从库，再依赖MHA（Master High AvAIlability）系统发起主动切换，最终下线旧节点完成集群拓扑变更。
通过备份搭建级联集群，完成新集群数据同步，再通过断级联+域名切换的方式完成集群变更。
落地方案的选定，重点考虑对业务的影响，哪种方案又快又稳对业务感知又小就选哪种，毫无疑问，方案二胜出。级联方案还有一个明显优势，新集群搭建过程中可以平滑升级负载均衡（CLB替换TGW）
MySQL集群迁移切换的风险非常大，稍加操作不当就可导致整套集群不可用，极端情况下可能直接让线上服务停摆。转转线上MySQL集群数量较多，如何又快又稳完成MySQL机房迁移工作？
通过备份扩容新集群，并与老集群建立级联关系，提前搭建好所有待迁移集群级联。由于转转采用单机多实例部署的架构，新建集群时得重点考虑混合部署带来的问题，需要提前整理各集群单实例磁盘、内存占用数据。在开发自动搭建级联集群脚本时，需要同时兼顾机器负载均衡和资源成本。
限制逻辑：
级联搭建过程：
核心集群间的上下游关系错综复杂，尤其是交易库和商品库。如果停写一套集群，其他好几套关联集群也会受影响。另外，尽管当前部分业务方具备双写能力，能够应对切换停写带来的影响，但集群数量太多，并非所有业务都有足够人力成本投入额外开发。综合考虑，与其花费大量人工成本去梳理上下游关系和额外开发，不如在凌晨低峰期短暂停服，批量切换核心集群。这项决定意味着我们需要具备过硬的批量操作和恢复能力，务必将操作时间进一步缩短，给测试、开发留足验证时间，尽量减少停服时长。
整个迁移周期内存在大量操作，需要降低人工误操作风险，同时对操作时间也有一定要求，因此，所有操作都需要实现自动化。对于关键步骤应当解耦处理，自动化模块需要能够独立运行，所有模块相互间形成闭环，当切换存在问题时能快速定位故障发生位置，及时回滚。在闭环中实现：
我们将线上集群分为3个等级，由高到低依次为P1、P2、P3，各等级占比约为1:1:1
我们正不断推进和完善集群服务分级管理，对于达到一定规模符合等级要求的集群，我们将投入更多精力、提供更多的资源去支撑高等级集群的可靠性及性能。
整个切换周期内，新、老集群的前、后置检查必不可少。切换前后配置不一致可能引发故障，尤其是一些关键参数配置。
前置检查：
后置检查：
完成各项自动化代码开发后，先通过测试集群进行多轮批量切换验证，随后按照集群等级开始线上集群切换。对于P3集群，由于切换操作对业务的影响较小，但又不同于测试集群，P3切换过程中能够反馈线上大部分集群可能遇到的问题。采用灰度切换验证，摸着石头过河，把意料之外的浑水都淌一遍，不断迭代自动化脚本。
灰度切换顺序：
灰度切换验证期间遇到的问题：
按标准化运维，同一集群同一角色有且仅有一个域名，但线上集群存在一套集群使用多个主库、从库域名的情况。在流量切换时，需要兼容处理多域名问题
部分老集群元数据长时间未维护，实例信息、域名指向信息可能有误。在迁移切换前，需要花精力去校对最新数据
转转线上MySQL集群规模400+，需要在9月27日凌晨停服期间完成所有集群切换。P3、P2集群在停服前已完成批量切换，剩余P1核心集群累计100+，平均耗时10s/套，半小时内结束战斗。停服期间因前期已规避大部分问题，切换过程非常流畅，后续的验证、压测也均符合预期。
关于作者
黄建波，转转DBA。主要负责转转MySQL运维及数据库平台开发。
京公网安备 11010802035086号