在单机模式 下我们部署了 databend-meta 和 databend-query 两种角色(参考:基于 minio 部署单实例 Databend ),其中 databend-query 是计算节点,无状态模式,这种架构也有直接用于生产的。实际上生产环境推荐至少部署三个 databend-meta 组成集群,databend-query 可以是一个节点,而且可做到不使用就关闭。如果你使用的是公有云上对象存储,就不用担心对象存储的高可用。下面我们描述一下 Databend 的集群环境搭建。
Databend 集群中的概念
在 Databend 集群中分为两个角色:databend-meta 集群和 databend-query 集群。其中 databend-meta 集群要求先启动,它在生产环境中建议 awayson 状态,并至少 3 个节点;databend-query 集群,可以是多个。
在生产中,我们推荐可以全局部署一个 databend-meta 集群,databend-meta 对资源消耗不高,可以和其它程序共用资源。
databend-query 默认是最大能力的并发,在单个 databend-query 节点下,一个 SQL 会尽最大努力把单节点的所有 CPU CORE 间并发;在集群模式下,databend-query 会把计算在整个集群中做并发调度。
集群资源隔离
在 databend 集群中,资源隔离有几个重要的概念: tenant_id , cluster_id, max_threads 为了让大家更好的理解 databend 集群,我们需要先理解一下这三个概念。
-
tenant_id 称为:租户 id,用于标识 databend-query 属于哪个租户下面,当租户 tenant_id 一样时,这个 databend-query 就可以获取该租户下的:用户列表及权限,对应的数据的定义相关等。
-
cluster_id 称为:集群 id , 这个参数依附于 tenant_id,需要首先看它在哪个 tenant_id 下面,然后可以获取对应的 meta 数据,之后再看是不是有同样的 cluster_id 成员。如果遇到同样的 cluster_id 成员就自动组成集群,可以在 system.clusters 表中查询到,SQL 请求到该节点后,算力会在 tenant_id 和 cluster_id 一样的节点间协调。对于 tenant_id 一样,cluster_id 不一样的,可以起到算力隔离,但大家共享一份数据和用户列表。
-
max_threads 控制一个 sql 在 databend-query 上可以用到多少个 cpu core, 默认是节点支持的 cpu core,例如有一些复杂 SQL 在内存不足的情况下通过 max_threads 限制并发的数量,减少内存的占用。
databend-meta 集群
假设 databend-meta 集群三个节点:192.168.1.100,192.168.1.101,192.168.1.102 这三个节点上同时部署 databend-query 架构如下:
大概搭建信息如下:
节点 | ip | id |
---|---|---|
192.168.1.100 | 192.168.1.100 | 1 |
192.168.1.101 | 192.168.1.101 | 2 |
192.168.1.102 | 192.168.1.102 | 3 |
其中配置文件中:raft_advertise_host 建议配置成 hostname 或是域名,这个需要 databend-meta 之间可以 ping 通及建立连接。可以暴力的修改 /etc/hosts
192.168.1.100 meta100
192.168.1.101 meta101
192.168.1.102 meta102
第一个节点(192.168.1.100),需要声明一个 single 节点
# databend-meta -c databend-meta-node-1.toml
log_dir = "./.databend/logs1"
admin_api_address = "0.0.0.0:28101"
grpc_api_address = "0.0.0.0:9191"
[raft_config]
id = 1
raft_dir = "./.databend/meta1"
raft_api_port = 28103
# Assign raft_{listen|advertise}_host in test config.
# This allows you to catch a bug in unit tests when something goes wrong in raft meta nodes communication.
# 为了安全,建议更改为内网 IP
raft_listen_host = "192.168.1.100"
# 如果配置成 hostname,需要注意 /etc/hosts 中可以解析
raft_advertise_host = "192.168.1.100"
# Start up mode: single node cluster
single = true
第二个节点 (192.168.1.101) 配置
# databend-meta -c databend-meta-node-1.toml
log_dir = "./.databend/logs1"
admin_api_address = "0.0.0.0:28101"
grpc_api_address = "0.0.0.0:9191"
[raft_config]
id = 2
raft_dir = "./.databend/meta1"
raft_api_port = 28103
# Assign raft_{listen|advertise}_host in test config.
# This allows you to catch a bug in unit tests when something goes wrong in raft meta nodes communication.
# 为了安全,建议更改为内网 IP
raft_listen_host = "192.168.1.101"
# 如果配置成 hostname,需要注意 /etc/hosts 中可以解析
raft_advertise_host = "192.168.1.101"
# Start up mode: single node cluster
#single = true
join =["192.168.1.100:28103","192.168.1.102:28103"]
注意 join 节点里不能出现本机的 ip
第三个节点(192.168.1.102)配置
# databend-meta -c databend-meta-node-1.toml
log_dir = "./.databend/logs1"
admin_api_address = "0.0.0.0:28101"
grpc_api_address = "0.0.0.0:9191"
[raft_config]
id = 3
raft_dir = "./.databend/meta1"
raft_api_port = 28103
# Assign raft_{listen|advertise}_host in test config.
# This allows you to catch a bug in unit tests when something goes wrong in raft meta nodes communication.
# 为了安全,建议更改为内网 IP
raft_listen_host = "192.168.1.102"
# 如果配置成 hostname,需要注意 /etc/hosts 中可以解析
raft_advertise_host = "192.168.1.102"
# Start up mode: single node cluster
#single = true
join =["192.168.1.100:28103","192.168.1.101:28103"]
注意 join 节点里不能出现本机的 ip
databend-meta 启动
meta.sh
#---
ulimit -n 65535
nohup bin/databend-meta --config-file=configs/databend-meta.toml
2>&1 >meta.log &
#end
./meta.sh
分别在三个节点启动 databend-meta, 如果启动出错及连接上不集群的情况,可以查看 .databend/logs 下面对应的日志,获取详细的说明。
Databend-meta 集群成员查看
curl 192.168.1.100:28101/v1/cluster/nodes