开门见山说结论: Doris这种OLAP组件,完全可以用Docker-Compose跑出生产级效果 ,关键是架构设计、配置文件细节和故障转移机制要理解到位。这篇文章我以三节点物理机/虚拟机为例,从目录规划、fe.conf/be.conf逐项拆解,到三节点FE集群初始化、BE注册,再到手动杀容器验证FE自动选主和BE数据自愈,完整走一遍。适合正在调研Doris容器化部署、或者已经被坑过想找一份可靠方案的读者。
先说下为什么用Compose而不是裸机或者K8s:Doris的元数据管理依赖FE之间的通信,配置相对集中,用Compose可以把配置文件、数据目录、启动参数全部固化在声明式文件里,换一台机器也能快速复现;而K8s虽然扩展性强,但引入额外复杂度,运维团队不熟悉的话反而容易出问题。三节点规模用Compose是性价比很高的选择。
1. 部署前的架构设计与规划
1.1 三节点上怎么分配角色
生产级Doris集群最小可靠形态是三节点,每台机器建议同时部署 一个FE和一个BE 。FE负责元数据管理、SQL解析与查询规划,BE负责数据存储和查询执行。这样的好处是:FE组成奇数节点(1个master + 2个follower),满足选主投票机制,避免脑裂风险;BE在同一批机器上,三副本数据可以均匀分布,任何一个节点宕机都不影响数据可用性。
节点角色分配表:
| 节点 | IP规划示例 | FE角色 | BE角色 |
|---|---|---|---|
| node1 | 192.168.1.10 | master(初始主节点) | BE节点1 |
| node2 | 192.168.1.11 | follower | BE节点2 |
| node3 | 192.168.1.12 | follower | BE节点3 |
这里说个容易被忽视的点: FE的奇数节点不是随便凑的 。Doris FE集群基于BDB JE(Berkeley DB Java Edition)实现元数据复制,master故障后会由存活的follower投票选出新master。如果FE是2个,一旦一个挂了,剩下一个无法形成法定多数,集群就只会处于只读状态。所以要么1个FE自嗨,要么3个起步,这是硬性约束。
1.2 镜像版本选择与容器启动方式
镜像建议直接用Apache Doris官方镜像。Doris 2.1.x是目前的稳定版本线,镜像在Docker Hub上有apache/doris仓库,分别提供FE镜像和BE镜像。我写这篇文章时用的标签是 apache/doris:2.1.5-fe 和 apache/doris:2.1.5-be ,生产环境尽量锁定具体版本号,不要用latest,避免某次拉取拉到行为不一致的新镜像。
启动方式这里我采用 覆盖默认entrypoint、手动执行启动脚本 的方案。为什么不直接用镜像默认入口?因为Doris集群初始化有严格的顺序要求:第一个FE要以master模式启动,后续FE要通过 --helper 参数去克隆元数据加入集群,BE要在FE就绪后才能注册。如果完全依赖镜像入口的自动启动,你很难控制这个先后关系。手动启动看着麻烦,但对排障和集群成员控制最有掌控感。
1.3 宿主机目录与端口规划
生产环境必须把容器的元数据目录、数据目录、日志目录全部挂载到宿主机。Compose文件里我先约定好每台机器上的目录结构:
/opt/doris/
├── docker-compose.yml
├── fe/
│ ├── conf/fe.conf
│ ├── meta/ # FE元数据目录,重中之重
│ └── log/
└── be/
├── conf/be.conf
├── storage/ # BE数据根目录
└── log/
端口规划方面,Doris默认端口分配:
| 组件 | 端口 | 用途 |
|---|---|---|
| FE | 8030 | HTTP Web UI |
| FE | 9030 | MySQL协议查询端口 |
| FE | 9010 | FE节点间edit log同步 |
| FE | 9020 | FE内部RPC |
| BE | 9050 | BE心跳上报 |
| BE | 9060 | BE Thrift服务 |
| BE | 8040 | BE Web服务 |
| BE | 8060 | BRPC服务 |
这三个节点如果部署在同一台机器上的不同容器里,端口会冲突,但我这里说的是三台独立节点,每台宿主机只跑一组FE+BE,端口可以完全复用默认值。如果基于单机模拟三节点,就得把容器端口逐一映射到不同的宿主机端口,等于是另一种玩法,后面我会单独说几句。
853




被折叠的 条评论
为什么被折叠?



