1背景作为国内领先的循环经济企业，随着转转业务的不断发展，基础服务设施已经到了“蜕变”阶段。当前使用的IDC资源已趋于饱和，难以满足后续发展需求。同时，随着腾讯云提供的负载均衡技术的迭代，需要将TGW（腾讯网关）替换为CLB（CloudLoadBalancer）。经过运维同学近半年的规划建设，新的IDC和负载均衡技术（CLB）已经升级上线。MySQL、TiDB、Redis等公共基础服务需要有序迁移切换。对于MySQL迁移工作，面临集群数量多、运行影响大、运维要求高等一系列问题，需要充分调研现状，制定合理方案，进一步降低业务服务感知.2迁移方案选择2.1方案一：扩容+主从切换通过备份扩容足够数量的从库，然后依靠MHA（MasterHighAvailability）系统发起主动切换，最后老节点下线完成集群拓扑变更。2.2方案二：级联切换通过备份搭建级联集群，完成新集群的数据同步，再通过断开级联+域名切换完成集群变更。2.3方案对比方案一：开发量小，扩容和MHA切换相对容易实现。但单个集群MHA切换时间超过30s，影响业务时间过长，机房迁移需要大规模切换能力，对MHA系统提出了极高的要求。依托高可用系统，保证在短时间内完成100多套集群的无损切换。方案二：原理简单，切换速度快，单个集群切换时间小于10s，对业务影响小。但需要大量自动化开发，如自动扩容、自动构建级联集群、自动前后检查、自动切换读写流量等，开发成本高。实施方案的选择主要看对业务的影响。选择哪个方案又快又稳定，业务感知少。毫无疑问，第二种方案获胜。级联方案还有一个明显的优势。在新建集群的过程中，可以平滑升级负载均衡（CLB替换TGW）。级联读流量切换示意图。级联写入流量切换示意图。3如何快速稳定地完成MySQL机房迁移MySQL集群迁移切换风险非常高，稍有不当的操作就可能导致整个集群不可用，极端情况下可能会直接停止在线服务。转转上有大量的MySQL集群。如何快速稳定的完成MySQL机房的迁移？3.1提前搭建级联。通过备份扩容新集群，与旧集群建立级联关系，预先搭建好所有待迁移集群的级联。由于转转采用单机多实例部署架构，在创建新的集群时，需要考虑混合部署带来的问题，需要对每个集群单实例的磁盘和内存使用数据进行梳理进步。在开发自动构建级联集群的脚本时，需要兼顾机器负载均衡和资源成本。限制逻辑：单机主库实例不超过5个，单机从库实例不超过10个，单机总实例不超过10个，单机内存不超过15个，磁盘占用不超过85%的关系错综复杂，尤其是对于交易和商品存储库。如果一个集群停止，其他几个关联的集群也会受到影响。另外，虽然目前部分业务方具备双写能力，可以应对切换停写的影响，但集群太多，并非所有业务都有足够的人力成本投入额外开发。综合考虑，与其花费大量人力成本梳理上下游关系和追加开发，还不如在凌晨的低峰期暂时停服，分批切换核心集群。这个决定意味着我们需要有优秀的批量操作和恢复能力。我们必须进一步缩短运行时间，为测试和开发留出足够的验证时间，尽量减少服务停机时间。3.3批量操作自动化，关键步骤解耦整个迁移周期中有大量的操作，需要降低人工误操作的风险，同时对操作时间也有一定的要求。因此，所有操作都需要自动化。关键步骤应该解耦。自动化模块需要能够独立运行，所有模块之间形成一个闭环。当交换机出现问题时，可以快速定位故障位置并及时回滚。闭环实现：构建级联集群，自动前后检查，自动批量读，批量写，自动kill旧集群连接，检测切换后，新集群连接从旧集群批量下线3.4集群分类我们将在线集群分为3个级别，从高到低分别是P1、P2、P3。每一级的比例约为1：1：1。我们在服务期内不断推进和完善集群服务分类管理。对于达到一定规模并满足等级要求的集群，我们将投入更多的精力，提供更多的资源来支持高等级集群的可靠性和性能。3.5切换前和切换后检查在整个切换周期中，新旧集群的前后检查是必不可少的。切换前后配置不一致可能会导致失败，尤其是一些关键参数的配置。预检：新集群vip-rshost链接连通性buffer_pool_sizesql_modeslave节点数级联延迟....3.6灰度切换验证完成各种自动化代码开发后，先通过测试集群进行多轮批量切换验证，然后根据集群级别开始在线集群切换。对于P3集群，由于切换操作对业务影响不大，但与测试集群不同的是，P3切换过程可以反馈线上大部分集群可能遇到的问题。采用灰度切换验证，摸着石头过河，把意想不到的浑水都倒掉，不断迭代自动化脚本。灰度切换顺序：单集切换，小批量切换（<10），大批量切换（>30），灰度切换验证遇到的问题：多域名问题标准化运维，同理同一个集群中的角色只有一个域名，但是线上集群中存在一个集群使用多个主从域名的情况。在流量切换时，需要对多个域名进行兼容处理。cmdb信息不准确。一些旧的集群元数据长期没有维护，实例信息和域名指向信息可能不正确。在迁移和切换之前，你需要花精力校对最新的数据。4最后转行中写到MySQL集群规模为400+，需要在9月27日凌晨停服期间完成所有集群切换，P3、P2集群已经在服务器前完成批量切换被关闭，剩下的P1核心集群一共100+，平均耗时10s/套，战斗在半小时内结束。停牌期间，前期避免了大部分问题，切换过程非常顺利，后续的验证和压力测试也达到了预期。关于作者黄建波，转DBA。主要负责转转MySQL运维和数据库平台开发。
