本来这篇文章是想着来测试 Doris 的 variant 功能好不好用的，但是，因为这个功能需要2.1及以上的版本才支持，而我当前的 Doris 集群版本为2.0.2。

于是，就只能先升级。

印象中这是第二次升级 Doris 集群了，还记得第一次从 Doris 1.x 升级到 2.0，用的是最原始，最费时的，先逐台升级 BE，再依次升级 FE 的手动模式(升级Doris2.0，到底有没有坑)。

那这一次，我决定换一种更省事的升级方式，用上次我部署过的 Doris Manager，虽然部署之后就几乎没有用过，但希望在这次集群升级中，能发挥出它的价值。

下面，是记录我用 Doris Manager 将 Doris 集群从2.0.2升级到2.1.2的完整过程。

第1步：准备安装包

下载地址：https://doris.apache.org/zh-CN/download。

这次就选这个页面打开后，默认的最新版本2.1.2：

下载完成后，把它放到其中一台 FE 家目录下(Doris Manager 要求的目录)。

好，安装包准备妥当。

第2步：打开 Doris Manager

进入到你的 Doris Manager 主页，点击右上角的「集群升级」

然后，会弹出下面的对话框：

从图中我框出来的部分你可以看出来为什么，一开始要把下载好的安装包给放到 FE 的家目录下了，因为升级程序会去那里找。

从对话框中可以看出来，Doris Manager 提供了两种集群升级方式，从描述来看，为了保险起见，我选择第一种(从上一次的升级经验来看，其实做不到真正的滚动升级)。

接着，点击「升级检查」

对其中的告警项，关系不大，忽略，点击「确认」。

第3步：异常处理

虽然说整个升级过程理论上是很简单的，但是在实践中，中间要是不出点幺蛾子，那几乎是不可能的。

就在点击上一步的「确认」之后，就抛出了第1个异常：

显示其中某个BE的文件打开数问题，这个问题很简单，找到对应的服务器，修改配置文件 /etc/security/limits.conf，把默认的 1024 给修改为大于上面提示的一个数值就可以。

接着，在升级过程中，又抛出第2个异常：

提示文件夹权限的问题。

从日志中可以看出来，Doris Manager 需要在 /usr/local/ 下创建用于升级的子目录，而当前集群，我用的是非 root 的 doris 用户启动的 Doris 服务，自然它是没有权限的。

所以为了解决这个问题，我决定手动创建这个子目录(所有FE跟BE)，然后赋权：

mkdir /usr/local/upgrade
chown -R doris. /usr/local/upgrade

但是，当我在所有服务器上都执行完上面的操作后，再次回到主界面后，就变成了这个熊样。

之前的升级按钮现在用不了啦，从文字提示来看，它需要你「重新接管集群」。

第4步：重新接管

这里的重新接管，并不是「重启」Doris Manager (因为重启了也没用)，而是需要你执行下面两个步骤：

4.1 取消原来的接管

也就是说，你当前已经用 Doris Manager 接管了现有集群，得先把它取消了。

按照图示的位置，点击「取消接管」。

4.2 再次接管

取消完成之后，当前 Doris Manager 就不再显示任何 Doris 集群了。

再次点击下面的按钮：

然后，看到下面的对话框(跟第一次使用 Doris Manager 一样)：

填上你的集群名称，选择「接管集群」。

然后，再次跟第一次使用 Doris Manager 一样进行配置。

如图配置完，总算是把升级前的集群给再次接管了回来。

接下来，继续升级。

第5步：重新接管后再次报错

重新接管后继续升级，但这一次又报错了，依然还是权限的问题，

除了之前升级程序需要在 /usr/local/ 目录下创建 upgrade 子目录外，这次它还要在这个下面再创建另一个子目录。

吐槽：

这里其实就暴露出当前用 Doris Manager 升级时的一个槽点，如果我当前用的是一个非 root 用户启动的进程，那么进程想要在 /usr/local 这种原本属于 root 用户权限的父目录下去创建子目录，就一定会产生权限问题。

最合理的做法，应该是把这种需要在升级过程中，必须用到的「额外目录」给建在一个让使用者自定义的、有权限的目录下，或者干脆原来的家目录下，这样就避免了上面遇到的权限问题。

为什么要建那么多跟原本的 Doris home 平级的目录呢？这到底是处于一种什么样的神奇思考。

那怎么解决？

这里我用了个骚操作，把 /usr/local 这个目录的所属者，再添加一个 doris 用户(注意：它原本的所属者跟权限是不变的)。

setfacl -m u:doris:rwx /usr/local

这样一来，doris 用户就有权限在 /usr/local 目录下想干啥就干啥了。

怎么样？这一招是不是要比你单纯用 chmod 777 要高级一些(估计大部分人都不知道这个玩法)。

解决完这个问题，又得跟之前的步骤一样重来一遍，先「取消接管」，再「重新接管」，再进行上面的配置。

第6步：升级终于步入正轨

看到下面这个画面，说明集群可以正常地升级了：

从输出的日志中，可以看出集群当前详细的升级状态。

升级成功后，是这样子滴：

小吐槽：

这里比较有意思的是，这个升级过程其实是没有「升级进度」的，在刚升级的时候，你可以看到那个转圈圈的地方显示的是：0/5，代表有5台机器需要升级。

但是一会之后，它就直接啪叽一下，告诉你全部升级完成，完全没有中间过程的显示。

第7步：对比升级前后目录结构的变化

先看升级前 Doris Home 的目录情况：

再看升级后的 Doris Home 目录情况：

跟 Doris Home 平级的，多了3个显眼包目录「java8」、「upgrade」、「upgrade_xxx」。

看到这里，其实也引出了另外一个槽点，那就是如果你光看这个目录结构，你知道自己当前使用的，是哪个版本的 Doris 吗？

以及，新版本用的配置文件和对应的 jar 依赖，在哪里呢？(一番仔细辨认之后，发现在 upgrade 目录里)。

这无疑给你后续的运维增加了一定难度。

第8步：接管升级后的集群

这个时候，回到 Doris Manager 的主页面，

点击这里，验收新集群。

进入到命令行，用 show frontends/backends 命令，查看当前集群运行实例的版本：

至此，整个 Doris 集群升级完成。

最后

从这次用 Doris Manager 来升级 Doris 集群的总体表现来看，体验还算可以。

虽然过程依然有些磕磕绊绊(主要是升级过程中需要创建多个子目录造成的权限问题)，但相比之前的纯手动升级模式，效率上还是要高很多。

但是，凡事都有两面性，虽然用 Doris Manager 来升级 Doris 集群简化了很多步骤，但是升级完之后，新集群在服务器上的目录结构，变得没有之前清晰，给运维增加了难度，可能后续要更加依赖 Doris Manager。

现在，我的 Doris 集群就是当下最新的版本啦，下一篇，咱就着手体验它的 variant 功能吧。