背景
此篇博客的源自于OceanBase社区论坛内一位名为皇甫侯的热心用户所提的建议，希望向OceanBase的用户介绍OceanBase的版本升级路径。本文以一个版本升级为示例，汇总了对用户而言比较重要的版本升级要点，期望通过这份分享，能让读者在阅读之后有所收获。
OceanBase的产品版本号
在介绍升级路径之前，先简单介绍一下 OceanBase 的产品版本号，产品版本号代表 observer 的版本，每次发版时都会推高版本号：
- 版本号的第一位代表架构的级别，修改架构才会推第一位版本号，目前（2024.09.05）最新版本是 4。
- 版本号的第二/三位，代表新增了不同级别的大 feature。
- 版本号第四位，则是代表每个分支版本下，定期对一批 bugfix 进行集中打包后发布的 BP (Bundle Patch) 版本。
这里需要注意的是，在前三位相同的情况下，第四位越大则代表当前版本推出越晚。前三位不同的情况下，无法通过产品版本号比较获得产品推出时间，因此一些 bugfix 是否存在需要根据产品拓扑图决定。
在每一位版本号后面还可能会有后缀，例如 CE、LTS、HF 等：
- CE（Community Edition）代表社区版。
- LTS（Long-Term Support）代表长期支持版，会在这个版本，长期解决稳定性 bug。
- HF（HotFix）表示只增加了关键 bugfix 的版本，旨在解决个别 “走投无路” 难以绕过的问题。
- GA（General Availability）代表稳定版本，是生产环境（即正式使用环境）下安全可靠的，可以广泛部署和用于日常业务操作的版本。在官网上可以看到 4.3.1 就是一个 GA 版本。
例如下图中 4.2.1_BP8(LTS) 就表示是 4.2.1 这个版本中进行过 8 次 Bundle Patch 的长期支持版本。
Barrier 版本
我下载了一个 4.2.3.1 的 observer，想测试下通过 OCP 把很久很久之前部署的一个单机的 4.1.0.1 给升级到 4.2.3.1 版本（测试集群是单机单副本，所以没法儿轮转升级，只能停服升级）。
本以为吃着火锅唱着歌就能把级给升了，结果不巧，OCP 说还需要给它上传一个额外的 barrier 版本。也就是说，需要下载两个 observer 的 binary 提供给 OCP，一个是需要经停的 4.2.1.2，一个是终点站 4.2.3.1。
提供完了 barrier 版本的包就不用管了，OCP 会帮你把集群直接升级到最终的 4.2.3.1 版本。
正好也趁这个机会，在介绍升级拓扑之前，先说一下什么是 barrier 版本，以及 barrier 版本的作用。
因为 OceanBase 在很多版本之间，都支持不停机地轮转升级，也就是各个低版本的 observer 会轮流替换成高版本，只要保持多数派还在就可以持续对外提供服务。所以在集群升级过程中，高版本的 observer 需要以低版本的模式持续运行一段时间，直到所有低版本的 observer 全部被替换成高版本为止。因此高版本需要继续保留低版本上的老代码。也就是说，即使低版本的功能在高版本上被废弃了，为了支持不停机升级，高版本的 observer 中也需要保留被废弃掉的古老代码。
为了减少维护版本之间升级兼容性的开销，避免让一个超级古老的版本直接升级到当前最新版本，带来大量的兼容代码维护负担。OceanBase 引入了一个 barrier 版本的概念。barrier 版本指的是某个低版本升级到某个高版本过程中，必须要经停的版本。在此 barrier 版本之前的版本，必须要先升级到 barrier 版本，才能继续升级到后续版本。这样研发同学在代码中，就不必考虑最新版本和上一个 barrier 版本之前的各种兼容性问题了。
如果大家觉得上面这两段介绍 barrier 作用的文字实在难以理解，也没有关系。只要看懂下面两张图，能够了解什么是 barrier 版本，基本也就够用了。
下图中有五个版本 A、B、C、D、E，其中 C 是 barrier 版本。对于 A、B 来说，都可以直接升级到 C。对于版本 C 来说，可以直接升级到 D 或 E。但是 A、B 无法直接升级到 D、E，他们升级到 D、E 的路径上，都需要经停版本 C，即先升级到版本 C，再升级到 D、E。
另外一个需要注意的点是 barrier 是针对某个版本的，即这个 barrier 可能对一些版本是 barrier，升级必须经停，对另一些则不是 barrier。
下图中有四个版本 A、B、C、D，其中 C 对于 A 来说是 barrier版本，那么如果 A 要升级到 D，就必须要经停 C，无法直接升级到 D，整个升级流程是 A -> C -> D。而 C 对于 B 来说不是 barrier 版本，所以 B 可以直接升级到 D。
这里需要注意的是，上面写的 “经停” 并不代表需要停机升级，只是比喻升级过程需要经历先升级到 barrier 版本，再升级到目标版本的这样一个过程。
升级拓扑
经停了 barrier 版本这一部分内容之后，终于来到了升级拓扑。定义升级拓扑图的文件叫 oceanbase_upgrade_dep.yml，感兴趣的朋友，可以点开前面的链接看看 github 中的对应文件，文件里有不少有价值的中文注释供大家参考。
这个文件会放在安装目录里，不同版本的内容略有不同，因为发现编译安装和通过 OCP 安装的文件路径好像还不太一样，所以就请大家自行 find 下吧。
升级拓扑主要由以下部分组成：
- version: 待升级的版本，或者升级过程中经过的版本。
- can_be_upgraded_to：当前版本可以直接升级到的版本号。
- deprecated：缺省为 False。如果为 True，表示这个版本已经废除。可以作为升级的起点，可以作为升级过度版本，但是不建议作为升级目标版本。
- require_from_binary：缺省为 False。如果为 True，表示是上面提到的 barrier 版本。
- when_come_from：一般是一个列表，伴随 require_from_binary 出现，表示从列表中的版本升级时，需要经停当前版本。
上图是一个升级的例子，为方便大家理解做了一些简化，不代表某个真实版本升级拓扑（不同版本的真实升级拓扑详见安装路径中的 oceanbase_upgrade_dep.yml 文件，一般可能会比上图略微复杂一些）。
图中左边有四个版本，分别是 4000、4001、4100、4200（这里偷懒省去数字之间的点号），其中 4100 是一个 barrier 版本，when_come_from: [4.0.0.0] 表示当低版本是从 4000 升级过来时，需要经停 4100。
但是因为 when_come_from 列表中没有 4001，所以 4001 可以直接升级到 4200，不需要经停 4100。这里再次强调下 barrier 版本是相对于某个版本而言的，例如这里的 4100 相对于 4000 是 barrier 版本，但是相对于 4001 则不是 barrier 版本。
大家可以这么理解：整个升级文件构成了一张类似于上图中右侧的有向无环图，整个升级流程就完全展示在这张升级拓扑图上。除非某个 barrier 版本指定说从某个特定的起始版本升级上来就需要经停它这个版本，否则就可以继续在这个图上往后不经停，直接升级到目标版本。（这段话稍微有一点儿绕，大家结合上面这个例子理解下~）
升级流程和升级脚本
因为这部分内容过于开发者向，考虑到这篇博客的读者可能绝大多数都是 OceanBase 的使用者或 DBA 同学，为了不浪费大家的宝贵阅读时间，这里暂时就先略去不讲了，哈哈~
实话实说，这部分内容虽然我略知一二，但非内核开发同学完全没必要了解，并非故意不讲，望大家谅解。这里先留一个坑位也不是吊大家胃口，而是日后如果真的有开发者提出诉求，方便我直接在这里动笔补上相关内容。
What Else
最后在这里给社区论坛中新增的 “官方精选” 板块 做一个介绍。“官方精选” 是汇聚了由）OceanBase 团队精心挑选或创作的内容。包括但不限于：
- 产品公告：OceanBase 内核及平台工具发布的新特性，以及产品的重要更新；
- 问题精粹：取之于论坛的优质问题、排查过程和结论，并会增加相关的技术解析；
- 互动精华：在论坛帖子中发现的有趣的问题和相应的分析，以及从用户贡献的内容中精选出的具有代表性的讨论或解决方案；
- 实践指南：通过不同行业和不同场景的最佳实践，分享经过验证的架构案例和配置建议；
- 其他：与生态上下游的联合解决方案等等。
如果大家在社区论坛中，写出或者看到优质的帖子，可以随时 @ 兹拉坦 进行投稿，如果内容被官方精选板块选中，会有相应的积分奖励。如果大家对官方精选板块有任何建议，也可以随时 @ 兹拉坦 进行吐槽，我们会改到令大家满意为止~
OceanBase 云数据库现已支持免费试用，现在申请，体验分布式数据库带来全新体验吧 ~
