GaussDB(DWS)数据库集群管理系列-在线升级/补丁【这次高斯不是数学家】
一、软件升级的意义
不断更新和演进是软件的一个重要行为,升级和补丁是软件更新演进的重要保证。伴随着新特性不断推出和历史问题修复,软件升级和打补丁显得格外重要。软件升级和打补丁需要满足如下要求:
-
软件版本的无缝、平滑过渡。
-
业务中断时间尽量少,以至于在线。
-
用户体验前向兼容。
而数据库升级比其他软件升级更为复杂,不光是软件本身的更新,还要支持其管理的数据的升级。数据库升级需要考虑如下因素:
-
软件升级,即软件本身的更新。
-
元数据升级,即管理数据的方式的更新。
-
业务数据升级,即用户数据的升级(可能涉及)。
对于云上数仓服务,SLA和高可用是关键竞争力指标。升级作为计划内停机的操作之一,云上客户希望能够尽可能降低升级窗口对于业务的影响。另一方面,每次升级都是一个高风险操作,新版本数据库的功能和性能,在生产环境往往有各种难以预估的影响因素,云上客户希望能够在升级后发现功能性问题,性能问题,或者兼容性问题时可以紧急回退到老版本减少对业务的影响的功能。因此对于在线升级和升级回退的诉求很高。
二、业界大数据产品升级分析
升级操作是数据库计划内停机的主要原因之一,对于数据库的高可用指标有着重要的影响。为了尽可能减小数据库升级操作对于业务的中断,业界提出了各种数据库在线升级的技术。
根据一次升级操作所涉及的变更范围,数据库升级主要可以分为三类:补丁升级,二进制升级和大版本升级。其中,
- 补丁升级主要用于修复代码上的缺陷,一般可以通过热补丁技术实现在线的升级。
- 二进制升级主要用于代码上较大幅度的修改和实现优化,对于节点内或节点间多进程share-everything构架的数据库(如Postgresql单机或Oracle RAC集群),较容易实现在线的升级,对于节点内多线程share-nothing构架的数据库(如GaussDB),切换二进制会导致至少一次的客户端闪断(即使采用主、备滚动升级的方式)
- 大版本升级主要用于大颗粒新特性的发布,和二进制升级最大的区别在于,大版本升级涉及数据库系统表的修改,执行时间更长、复杂度更高,业界一般有两种大版本在线升级方案:以Oracle为代表,采用基于(临时/永久)逻辑复制主、备滚动升级的方式,在主、备切换时会产生至少一次的客户端闪断;以Snowflake为代表,采用多版本系统表的在线升级方式,升级过程对业务的影响与二进制升级类似。
三、GaussDB(DWS)升级能力
GaussDB(DWS)从8.1.2版本支持了在线补丁能力,冷补丁期间业务秒级闪断,热补丁完全在线,业务不中断。
在8.1.3版本支持了在线升级能力。最早支持8.1.1版本在线升级到8.1.3版本,数据库升级过程中,对业务仅产生闪断一次的影响(10秒以内)。
在8.1.3版本支持了升级回退能力,升级完成后发现问题可无损回退到老版本。
-
在线补丁
在线补丁根据使用场景不同分为二进制替换升级(冷补丁)和热补丁。
二进制替换升级 |
热补丁 |
|
适用场景 |
漏洞修复 小需求 例行补丁 |
漏洞修复 紧急补丁 |
升级耗时 |
小于15分钟 |
分钟级 |
业务影响 |
业务秒级闪断 |
完全在线 |
关键技术 |
软件多工作区 秒级切换进程 |
函数级修改热加载 不需要重启进程 |
-
冷补丁原理-软件多工作区安装
废弃原来的就地模式,采用软件多工作区模式,切换工作区在秒级以内,可以减少替换新二进制对业务中断的影响。
-
冷补丁原理-二进制秒级切换
切换到新工作区后,采用快速切换进程的模式,分批次把数据库进程切换到新版本,切换进程也是秒级操作。
-
热补丁原理-预留补丁区,新老函数跳转
1)在GaussDB主进程预留一块补丁区域,进程启动时完成补丁区的初始化操作。
2)打补丁时把补丁文件里面的补丁函数动态加载到热补丁区,加载操作秒即完成。
3)并在原函数的入口处,加入跳转指令,当原函数被调用时,跳转到补丁区执行补丁函数。
示意图如下:
-
在线升级
8.1.3版本及以后支持在线升级。不光支持8.1.3向后升级走在线升级,还支持8.1.1.x和8.1.2.x版本升级到8.1.3版本走在线升级。
在线升级 |
|
适用场景 |
新特性发布,吸收业界最新技术,快速响应用户需求,持续交付可靠的产品 |
升级耗时 |
小于30分钟 |
业务影响 |
业务秒级闪断 |
升级路径 |
8.1.1/8.1.2 -> 8.1.3及以后 |
关键技术 |
系统表结构硬编码化 系统表结构和系统表数据的多版本兼容 软件多工作区,秒级切换二进制,主备滚动切换 |
在线升级除了复用在线冷补丁的机制外,还使用了如下技术:
-
在线升级原理-系统表结构内置
把系统表的元数据内置到二进制中,切换到新的二进制后,无需执行系统表元数据升级脚本,直接可以使用新版本的系统表。消除了修改系统表对业务中断的影响。
以下图1是编译构建时内置系统表元数据的逻辑,图2是新版本二进制启动时新版本系统表元数据加载过程。
-
在线升级原理-系统表结构和系统表数据多版本兼容
切换到新版本后,系统表的元数据直接使用内置的结构,但是系统表物理元组还是老版本的,为了保证数据库正常提供服务,还需要保证系统表元数据和系统表元组数据多版本兼容,以下为典型的三种兼容性场景。
-
升级回退
8.1.3版本及以后支持升级回退,升级观察期发现问题可快速无损回退到老版本。
升级回退 |
|
适用场景 |
升级后观察老业务在新版本是否兼容,功能是否受损,性能是否劣化,发现问题紧急回退 |
回退耗时 |
小于20分钟 |
业务影响 |
业务秒级闪断 |
回退路径 |
8.1.1/8.1.2 -> 8.1.3及以后 |
关键技术 |
升级后可体验回滚兼容的新特性 升级提交后支持动态开启回滚不兼容的新特性 升级回退业务秒级闪断 |
当数据库支持在线升级后,在升级过程中有业务持续接入,如果升级失败,需要支持回退到老版本。同理,升级成功后也能够回退到老版本,那么升级回退就天然支持了。但是升级成功后如果使用新功能,如果涉及新格式的数据生成,则可能导致回退后老版本二进制无法读取新格式的数据,从而影响回退后的数据库功能。因此在线升级提出了“升级观察期”的概念,升级成功后即自动进入升级观察期,升级提交后则结束升级观察期。
升级过程中:可以运行老业务,新特性(回滚不兼容)自动关闭,新特性(回滚兼容)可以使用。
升级观察期:可以运行老业务,新特性(回滚不兼容)自动关闭,新特性(回滚兼容)可以使用,随时可以快速、无损回退到老版本。
升级提交后:新特性可以自由开启,可以使用任何新老特性。无法再回退到老版本。
在线升级和升级回退流程各阶段简图如下:
四、升级的进一步演进
GaussDB(DWS)在8.1.3及以后版本实现了在线补丁、在线升级和升级回退能力。业务影响极致缩减到秒级。后续将进一步致力于构建业务完全无感知的在线升级,通过上层路由、中间件或客户端的查询重做,可以降低二进制升级和大版本升级过程中服务闪断对业务的影响。
【这次高斯不是数学家】有奖征文火热进行中:https://bbs.huaweicloud.com/blogs/345260
- 点赞
- 收藏
- 关注作者
评论(0)