升级Doris2.0，到底有没有坑

最近看Doris的官方文章和活动，都在如火如荼地宣传新出的 2.0，各种快多少倍，又出了哪些花里胡哨的新功能等等。

了解我的小伙伴应该知道，我对这些开源软件新版本的所谓新功能，和对应提升多少倍的效率，一向都保持着审慎、怀疑的态度。

毕竟之前测试对比过太多这种开源新秀，大部分都不能尽如人意，甚至是失望。

那面对这次Doris重大版本的升级，它的表现又会如何呢？

咱先把它装起来试试。

带着疑虑，伴随着好奇心，驱使我再一次打开了Doris官网的下载页面，随着一声鼠标的“啼嗒”，最新版本的 Doris2.0.2 已经在快马加鞭向我驶来。

由于之前我部署的Doris版本为1.2.3，从官方文档提供的升级描述来看，我并没有清楚的看出能否直接从1.2.3平滑升级到2.0.2，于是特地请教了Doris官方的PM，在得到确认的回复后，我的Doris升级之路，就此开启。

0. 何谓升级

不知道你们有没有去认真思考过这个问题，一般而言，对于软件的升级，根据我这些年的实践经验，认为可以分为两大类：

1.在全新的机器上部署新版本的软件，启动新软件的服务后，再通过数据传输工具，将老版本的数据同步到新软件中；

2. 用新版本的软件，来直接替换老版本的，替换其中依赖的核心类库，但保留老版本的配置，和数据路径。

对于第1种升级方式：

最大的优点就是技术难度低，且升级风险小，对于一些比如规模较大，或者拥有重要数据的集群来说，这种升级方式更加保险，服务可以保证完全不停，丢数据的风险更低。

但缺点是，这个升级过程是渐进式的，比较缓慢，需要经历一段时间周期，而且需要你的硬件资源相对充裕，一般比较适合那些不差钱的比如银行、电信，或者政府部门。

对于第2种升级方式：

优点是不需要额外的硬件成本，且升级时间短。

但缺点是，有一定的升级风险，在升级过程中，很有可能停止服务，升级后服务无法正常启动，原来的老数据无法在新版本的集群中被识别，或者存在兼容性不好的问题，一般比较适合数据量不大，或者数据重要性没有那么高的场景。

那么对于我的这次Doris升级，很显然，属于后者。

1.升级准备

最重要的准备，当然就是先去下载对应的安装包了，当我再次进入到官网的下载页面发现，咦... 好像变得有点不一样了。

除新增了几个Doris的新版本外，从1.2.4开始，还新增了在选择这些较高版本时，根据CPU的特点，是否支持avx2指令集。

虽然我不知道这玩意在对数据进行查询运算时，能具体起到什么样的作用，但根据 Doris 官方的人描述，除开一些少数的国产CPU外，一般我们常用的英特尔，或者AMD的CPU都是支持的。

具体怎么验货，官网也给出了验证方式：

如果能匹配到这个关键字的输出内容，则证明支持，于是就可以下载带avx2标注的版本。

然后，再根据官网要求，关闭集群副本修复和均衡功能(升级完再改回来)：

2. 升级开始

根据官方文档的描述，Doris 可以支持在线的滚动升级，所谓滚动呢，就是那么多服务，在不需要停止的情况下，我们可以一个服务接一个来逐个更新、替换、然后启动，直到所有服务都更换成最新的版本。

但是呢，理论归理论，实际上行不行，咱等操作了才能知道。

2.1 先升级BE

同样，根据官方文档的描述，说Doris老版本的FE是可以兼容新版本BE的，于是建议先升级BE。

好，说干就干，具体做法，就是先把BE相关的软件包拷贝到其中一台BE节点。

跟老版本不同的是，新版本把FE跟BE的软件包融合到了一个大的文件夹里面(下载后的.tar.gz包解压之后)：

需要解压之后，单独把子文件夹里面的be目录复制到目标服务器。

瞅一眼其中一台BE原本的目录：

可以看到，在我之前的版本(1.2.3)里，我用了一个符号链接目录，来做指向，目的就是为了以后版本升级时，不需要去修改配置文件中的 doris 家目录的绝对路径，起到解耦的作用。

首先，需要修改配置文件。

先来看下新旧版本配置文件的变化：

老版本的配置文件

新版本的配置文件

可以看到，跟老版本相比，新版本多了一个配置文件，目前不知道是用来干嘛的，官网也没提它，暂时忽略。

我们修改关键的配置 be.conf 就好了，具体做法，就是把原来的老版本的这个文件给复制过来就可以了，其实不用改具体的内容。

然后，保险起见，备份当前BE节点的数据目录。

虽然官网没有明确说需要这一步，但是作为一名干过运维的老鸟程序员，深知备份的重要性，万一升级途中出现什么幺蛾子，咱还有后悔的余地。

好了，接下来就是要停掉当前老版本BE的服务，然后启动新BE的服务了。

再kill掉当前BE服务；

再将doris-be的符号链接给链到新版本的be目录上：

启动新be服务：

查看日志，没有发现异常：

再通过FE端(MySQL客户端连接FE)查看BE的状态：

通过show backend命令查看

可以看到，目前为止，对这个BE的升级就完成了，且没有发现问题。

既然这样，那咱就可以重复刚在的步骤，把剩下的BE全给升级了。

一番猛如虎的操作之后，我的3台BE已经全部升级完成，很顺利，暂时没有坑。

而且我还试了一下，在还没有升级FE的情况下，用一个简单的SQL去查一下当前集群里面的表，发现使用是不受影响的。

2.2 升级FE

既然BE升级如此顺利，那这个好运气能不能延续到FE身上呢？

带着这个疑问，咱一起来试试看。

还是先看下新版本的FE，在配置文件中跟老版本有哪些差异：

老版本配置目录下的文件

新版本配置目录下的文件

可以看到，新版本的配置文件少一个，但多出一个空目录，这些现在都可以不管，咱暂时只用关心核心的配置文件 fe.conf.

看了官方文档的说明，对于FE的升级，官网建议我们额外找一台机器来测试启动新的FE服务，不要一开始就在原本的FE上进行升级：

看了官网这有些复杂的描述内容呢(因为我不理解为什么要修改这个cluster_id，反正我肯定不会去改)，于是我决定，不接受它的建议。

咱直接就从原本的FE集群中先找一台机器，直接开始。

具体做法，还是跟刚才的BE一样，将老的 fe.conf 配置文件拷贝到这台FE节点新的配置目录下，这样就不用逐个去修改新版本的配置文件了：

同样，为了防止升级失败，最好备份当前FE节点的数据目录：

另外，跟BE一样，我们需要修改之前doris-fe的符号链接到新版本的doris上，以及修改对应文件夹的所属者为doris用户(为了规范)：

接下来，准备重启FE服务：

根据顺序，应该是先停掉当前老版本的FE服务，然后再启动新版本的FE服务，可就在我停掉当前机器的FE之后，发现，另外两台FE机器的服务居然直接挂了。

突然，一种不祥的预感向我袭来，我感到，坑怕是要来了。

果然，当我启动这台新版本的FE服务时，看到日志的输出如下：

新版本的FE一直处于 unknown 状态，这就让人很惆怅，因为你根本不知道它是因为什么具体原因而导致这样的。

再看这个时候，所有的BE节点都是启动的，但是BE的日志都显示无法连接到master。

心想，坏了，是不是因为这个master需要选举呢？

那既然需要选举，按理说一台FE其实也可以啊，自己选自己呗。

可是它现在貌似不行，是不好意思选自己吗？

如果是，那咱就再启动另一台FE试试，于是又在另一台FE中重复了刚才的操作。

当启动另一个FE新版本的服务时，发现，咦... 果然可以了。

此时，master就选出来了。

很快，我又用同样的操作，去升级了另一台FE。

至此，整个Doris服务恢复正常，大概检查了一下升级后的库名和表名情况，发现一切都正常，暂时没有发现丢数据，或者表不可用等方面的异常。

最后

这次升级其实算比较顺利，基本上没有什么坑，这也算是符合情理之中的。

本来对于一个软件来说，升级的原理其实都很简单，搞清楚这一点，即便中途出现了什么问题，也不难排查。

只不过，本次升级没有办法做到像Doris官网描述的“滚动式”，FE服务还是经过了短暂的停止，而且新启动的集群，原本的客户端连接在重新寻找新的master的时候，还有几次断开重试的现象。

客户端需要经历两次重试，才能连接到新的master，虽然谈不上什么问题，算略有瑕疵吧。

本次升级，只能算作为试用Doris2.0的“开胃菜”，至于它在后续数据读写方面的表现如何，咱下次接着聊...