项目纪实 | 业务不停机、升级0感知！万里数据库生产环境助力操作系统升级获客户点赞

为积极响应和落实国家、集团相关要求，某运营商省公司历时一个月将GreatDB数据库集群下Red Hat操作系统升级为BigCloud操作系统，以建立完善的IT自主可控体系，推动产业链生态发展。

源起：项目背景一览

2024年初，万里数据库接到某运营商省公司客户的需求通知：要将GreatDB 数据库集群下的所有操作系统升级为国产操作系统。于是，万里数据库项目团队立即展开前期调研准备工作，通过全面调研了解：业务系统升级前的现有环境中，生产环境使用了多套GreatDB分布式数据库集群，服务器超过20台（服务器采用x86架构，RedHat7操作系统），总数据量超过50TB，上层支撑着数十套业务系统。

02 选型：专业评估，规划最佳升级方案

经过对生产环境的全面仔细分析，万里数据库给出2套切实可行的升级方案：

一种方案是请客户提供一批新机器，部署国产操作系统后再 1:1 部署同架构的GreatDB 分布式数据库集群，然后进行数据迁移工作，最后将各业务割接至新的数据库集群；

第二种是依靠国产操作系统的升级工具，在线对操作系统进行升级，但这种方案对GreatDB分布式数据库的兼容性和稳定性来说，都是一个巨大的挑战。

方案1 VS 方案2

在这里插入图片描述

考虑到数据迁移成本及客户服务器资源紧张等多方面因素，为帮助客户实现降本增效，以最低成本完成操作系统升级工作，万里数据库经过与客户周密的讨论部署后，决定采用方案二推进升级工作。

03 挑战：正式生产环境下原地升级数据库面临巨大挑战

由于客户无法提供大量的新服务器资源，因此本次操作系统需要原地进行升级，即在正式的生产环境中完成操作系统替换，这就要求替换过程中业务不能停机，尽可能做到应用0感知，这对GreatDB分布式数据库的高可用切换能力而言，是一项非常大的考验。

与此同时，滚动升级过程中，万里GreatDB分布式数据库集群要同时运行在两种不用的操作系统上，这对GreatDB的兼容性而言，也存在较大挑战。

04 规划：制定升级+测试完备方案确保系统无故障

■ 升级方案

考虑到GreatDB 分布式数据库集群的特点，万里数据库决定采用滚动升级方式，分批对数据库集群中的服务器进行系统升级。滚动升级依赖于GreatDB分布式数据库强大的高可用切换能力，基本可以做到切主期间业务无感知。

GreatDB分布式数据库集群的各个组件均有冗余设计，且应用到数据库集群的链接通过F5实现负载均衡。这样一来，升级前将待升级服务器上的相关服务切换为从服务，切换成功后进行业务验证，无异常后将该服务器上的相关服务停止，然后等待系统运维人员使用系统升级工具完成系统升级。

接着，升级完成后更新相关依赖并启动数据库服务验证状态，待数据追平后再进行一次切换，将升级后的服务器切换为主节点，对外提供服务。升级后需要观察一个业务周期，一旦发现问题，即升级后的服务不能满足生产需求，则立即将主节点切换到未升级的服务器提供服务。

■ 测试方案

完备的升级前测试工作，是保障系统顺利升级的重要前提。为了保障系统顺利升级，万里数据库项目团队进行了多方面测试，包括：
1、线下搭建仿真业务环境，部署系统升级工具，验证系统升级可行性及对GreatDB 相关服务的影响，记录需要升级的环境依赖等；
2、线下进行一系列完备的测试工作准备，如功能测试、高可用测试、备份恢复测试等；
3、线上进行测试环境系统升级测试、业务功能测试、升级前后性能测试对比、高可用测试等，全面测试系统升级后是否满足业务需求。