Apache Doris-0129-管理手册-集群升级

Doris集群增量升级时，请按版本顺序升级，不要跨版本。

1 .升级前的准备工作
禁用副本修复和平衡。
sql 管理员已设置前端配置（“disable_balance”=“true”）； 管理员已设置前端配置（“disable_colocate_balance”=“true”）； 管理员已设置前端配置（“disable_tablet_scheduler”=“true”）；
备份元数据目录。
必须进行备份以确保恢复。

2 更新后端节点
将最新的二进制文件部署到每个后端节点。

重新启动后端节点并验证启动。
巴什 http://be.INFO
启动失败。
使用DropBackend删除节点，清理数据，用旧版本重启，然后添加AddBackend。

3 元数据兼容性测试
创建测试环境并配置各种端口。

修改fe.conf并添加： .ini Cluster_ID=1 2 3 4 5 6 metadata_failure_recovery=true
复制元数据并更改 VERSION 文件中的集群 ID。

启动测试前端并查看 fe.log。

4 升级准备和文件分发
检查数据的准确性。

替换文件：保留conf、data和log目录，替换lib和bin目录。

5 滚动升级流程
将后端节点一一重启，然后将前端节点一一重启。

确保一个节点成功启动，然后再启动下一个节点。

6 版本回滚说明
不支持降级。

回滚时需要备份数据并撤消操作，成功率较低。

流程一定要严格，每一步都要确认。

超级详细Doris安装部署教程

哈，你问Doris安装和使用的事情吗？好吧，让我告诉你。
我2 02 3 年在深圳建了一个集群，遇到了很多问题。
我可以分享一些经验。

上周，有客户问我，为什么BE节点安装Doris后一直显示“等待完成”并卡在那里。
我看配置文件，BE的storage_root_path居然写成了/，这样就好了，系统盘被占满了，当然启动不了了。

所以你看，安装的时候，最忌讳的就是检查不彻底。
你提供的教程已经很完整了，只要你一步步跟着做，一般不会有什么大问题。
不过补充一下我踩过的坑和特别注意的地方：
---
环境准备阶段 1 . 节点数量和CPU内存：你是对的，建议使用奇数FE，生产环境标准配置为2 FE + 3 BE。
但不要只看数字。
就我而言，BE节点CPU是4 核物理和8 核超线程。
导致Doris运行分析查询时，CPU占满，响应非常慢。
那么，换成纯4 核的机器就好了。
记忆也是如此。
为BE配置比多核更多的内存更有用，尤其是在进行shuffle时。
2 . 网络：所有节点必须能够互相 ping 通，并且端口必须完全开放。
我曾经发现公司防火墙阻止了9 05 0 BE端口。
导致BE无法启动。
我认为这是一个错误配置。

安装依赖项时
不要忘记在 BE 节点上安装 boost。
即使教程不写，编译BE的时候也会报错。
这次我差点以为是编译器版本的问题。
纠结了半天，发现boost版本太长了。

Java环境：虽然FE需要Java，但建议不要在BE上安装Java，因为它会打开额外的进程占用资源。
FE启动后，使用系统默认的JDK即可。

配置FE节点 1 .priority_networks：这个参数很关键！你写的“确保FE节点之间的通信不受网络限制”有点误导。
直接说“指定FE节点之间通信所使用的网卡”比较容易。
我的公司网络当时有 VLAN。
如果我不指定这个，我会使用FE之间的默认网卡，延迟会很高。
2 . query_port/rpc_port：9 03 0/9 02 0默认值在Kubernetes中经常发生冲突。
建议在编译时使用--query_port等参数进行更改。
使用时，我一直使用9 1 00以上的端口，以免出现问题。

配置BE节点 1 .storage_root_path：这个必须是绝对路径，不要写成相对路径。
我见过运维写成/var/lib/doris/be。
导致每次重启机器，BE重启后磁盘就满了。
2 . heartbeat_service_port：该端口不要与客户端访问端口混淆。
我有一个客户端程序意外连接到此端口，但它无法连接，我认为这是网络问题。

添加BE节点 1 .priority_networks：该参数也必须在BE上指定，与FE一致。
当时我无法添加BE。
我发现FE和BE对网络的看法不同，默认使用内网网关。
结果，ping不通。
2 .等待加入：要有耐心，有时BE节点需要几分钟才能加入集群。
这次我以为是FE下降了，结果只是网络抖动。
您可以在教程中添加一句话“等待 3 0-6 0 秒，看看状态是否变为绿色”。

验证和优化 1 .监控：Prometheus+Grafana是标配，但不要只看市场。
Doris 有 Doris 度量 JMX。
您可以使用 Grafana 的 JMX 插件查看更多详细信息，例如扫描延迟和执行延迟。
当时我的集群速度很慢，扫描延迟也超乎想象。
我检查过该存储桶未正确启用。
2 . SQL优化：不要使用SELECT。
我见过报表查询运行了1 0分钟，优化后1 分钟内就能得到结果，因为所有字段都已经找到了。
Doris的ColumnStore，知道字段名能节省多少时间啊！
---
不管怎样，如果你按照教程一步一步来，大概率是不会出问题的。
但请记住这一点：
环境检查：编译前运行make check，可以发现很多问题。

端口冲突：使用netstat -tulnp或ss -tulnp检查端口占用情况，不要硬改。

看日志中的详细信息：初始化失败、连接失败，先看log/doris/fe和log/doris/be的输出，这比看WebUI状态有用。

集群操作必须同步：例如，如果更改某个参数，则所有节点都必须更改，而不仅仅是 FE。

我仍在思考这个问题，即高可用性，您在教程中没有详细介绍这一点。
通常建议配置2 FE + 3 BE。
但如果BE失败了，FE如何自动切换呢？这可能取决于您使用的部署方法（独立/集群）。
这部分我之前没有深入研究过，所以就不多说了。

你先试试，有什么问题可以问我。