第1.2章:StarRocks部署--部署环境准备

本文详细介绍了StarRocks集群的硬件推荐、环境校验与准备,包括CPU、操作系统、服务器IP配置、集群时间同步、文件打开数限制、时区设置、防火墙端口配置以及JDK和mysql-client的安装。强调了必须支持AVX2的CPU、Linux CentOS 7及以上版本、固定IP、时钟同步和文件打开数限制的重要性,以及OpenJDK和mysql-client的安装步骤。

1.1 集群硬件推荐

StarRocks对服务器配置的基础要求不高,测试环境2核4G内存下也能够正常进行一些小数据规模的查询。在生产环境下或者我们比较关注性能时,StarRocks各实例推荐的硬件配置为:

实例名称

配置要求

FE

8核16GB万兆网卡 及以上(并发不高时可与BE混布)

BE

16核64GB万兆网卡 及以上 CPU必需支持AVX2指令集

Broker

无特别要求,通常与BE节点混布,与BE节点数量相同

为保证集群性能及数据安全性,我们建议生产环境最少使用三台1632G万兆网卡的服务器。假设node01、node02、node03均为符合要求的服务器,生产环境最小部署架构示例:

 

其中,node01部署一个FE作为Leader,node02部署一个FE Observer提供元数据备份。集群三个节点各部署一个BE,可保证生产环境数据使用StarRocks默认的三副本存储(测试环境可以使用单副本)。

在node01上我们还可以安装mysql-client。StarRocks兼容MySQL协议,推荐使用mysql-client进行访问,也可以使用SQLyog、DBeaver、Navicat、Datagrip等图形化工具,将StarRocks视为MySQL进行连接访问。

特别注意,一台机器上只可以部署该集群的单个FE实例,因为同一集群中所有FE实例的http_port需要相同。

此外,虽然一台机器上可以错开端口部署多个BE实例,但如果需要3副本数据,那么至少需要3台机器各部署一个BE实例,这是因为StarRocks的副本均衡策略不会将同一个Tablet的副本部署在同一个IP的BE上。

1.2 集群环境校验及准备

在了解了StarRocks集群所需的硬件配置后,我们还需要对集群服务器进行必要的环境校验及系统调优。StarRocks的运行环境准备可简单分为“必需类”与“优化类”两大类。在集群部署前建议结合情况完成下文列出的全部准备工作,因为“优化类”配置对StarRocks性能也会有一定的影响。

1.2.1 必需类准备

1.2.1.1 CPU检查

StarRocks的向量化技术需要CPU的AVX2指令集支持才能发挥效果,所以部署BE服务的机器CPU必需支持AVX2指令集。在Linux中,使用如下命令检查CPU是否支持:

[root@node01 ~]# cat /proc/cpuinfo | grep avx2

flags                   : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ss ht syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon nopl xtopology tsc_reliable nonstop_tsc eagerfpu pni pclmulqdq ssse3 fma cx16 pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand hypervisor lahf_lm abm 3dnowprefetch invpcid_single fsgsbase tsc_adjust bmi1 hle avx2 smep bmi2 invpcid rtm rdseed adx smap xsaveopt arat

有结果输出即表明CPU支持。如果无输出,则需要更换支持AVX2的机器。部分情况下,我们会在Windows系统下使用虚拟机安装CentOS作为测试环境,此时我们可以使用CPU-Z、AIDA64等工具在Windows下检查宿主机CPU的指令集支持情况

1.2.1.2 操作系统检查

StarRocks要求系统为Linux CentOS 7及以上版本(下文演示使用CentOS 7.6),内核版本建议在3.10以上,查看系统及内核信息:

[root@node01 ~]# cat /etc/redhat-release

CentOS Linux release 7.6.1810 (Core)

[root@node01 ~]# uname -a

Linux node01 3.10.0-1160.25.1.el7.x86_64 #1 SMP Wed Apr 28 21:49:45 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux
————————————————
版权声明:本文为优快云博主「流木随风」的原创文章,遵循CC 4.0 BY-SA版权协议,转载请附上原文出处链接及本声明。
原文链接:https://blog.youkuaiyun.com/ult_me/article/details/121493170

1.2.1.3 服务器IP配置

在部署FE或BE实例时,为了避免服务器多网卡情况下StarRocks无法准确判断出需要使用的IP,我们会在各实例配置文件中使用priority_networks参数绑定IP。

同时,由于当前StarRocks运行时会将集群内各实例绑定的IP等信息存储于本地目录中,若服务器节点内网IP改变,集群实例将无法正常运行(或需要通过较为繁琐的元数据恢复等操作进行处理),故运行StarRocks的服务器IP(内网)需要是固定的。服务器系统配置为固定IP操作见附录一:服务器配置固定IP。

1.2.1.4 集群校时

集群内各FE实例所在服务器最多允许5秒的时钟偏差,可使用NTP协议同步网络时间或进行集群内部校时。具体校时操作见附录二:集群时间同步

1.2.1.5 修改打开文件数限制

当打开文件数限制过小时,BE实例可能无法正常启动,使用ulimit -n查看文件打开文件数限制:

[root@node01 ~]# ulimit -n

1024

若返回值<65535,则需要修改/etc/security/limits.conf:

[root@node01 ~]# vi /etc/security/limits.conf

在末尾加入配置(表示:所有用户所有组,软限制和硬限制,对文件打开数,设为65535):

* soft nofile 65535

* hard nofile 65535

修改后需要断开远程工具(如Xshell等)后重新连接方可生效,或者,直接再临时修改一次,使用:

[root@node01 ~]# ulimit -n 65535

确认生效:

[root@node01 ~]# ulimit -n

65535

1.2.1.6 检查时区

为避免带有时间戳的数据在数据导入过程中出现时差问题,我们需要检查设置系统时区为Asia/Shanghai:

查看时区:

[root@node01 ~]# timedatectl

Local time: Tue 2021-09-07 19:31:28 CST

Universal time: Tue 2021-09-07 11:31:28 UTC

RTC time: Tue 2021-09-07 11:31:29

Time zone: Asia/Shanghai (CST, +0800)

NTP enabled: yes

NTP synchronized: yes

RTC in local TZ: no

DST active: n/a
————————————————
版权声明:本文为优快云博主「流木随风」的原创文章,遵循CC 4.0 BY-SA版权协议,转载请附上原文出处链接及本声明。
原文链接:https://blog.youkuaiyun.com/ult_me/article/details/121493170

若时区不为Asia/Shanghai,设置命令:

[root@node01 ~]# timedatectl set-timezone Asia/Shanghai

1.2.1.7 配置防火墙

[root@node01 ~]# systemctl stop firewalld

<think>我们正在处理一个数据库错误,错误代码为1105,errCode=2,详细信息是"There is no scanNode Backend available.[10059: not alive]"。根据引用[1]中的错误信息,虽然具体错误信息不完全相同(引用[1]是10002,这里是10059),但都是关于scanNode Backend不可用的问题。我们可以参考类似错误的解决思路。 可能的原因和解决方案: 1. 后端节点(Backend)不可用:错误信息明确提到“not alive”,说明负责执行扫描任务的后端节点已经宕机或失去连接。 - 解决方案:检查后端节点的状态,确保所有节点都正常运行。如果是分布式数据库,使用管理命令查看节点状态(例如,在Doris中,可以通过`SHOW BACKENDS;`命令检查BE节点状态)。如果有节点宕机,尝试重启该节点。 2. 网络问题:节点间通信故障可能导致节点被标记为不可用。 - 解决方案:检查节点之间的网络连通性,特别是报错的节点与其他节点(包括FE和BE)之间的网络。 3. 资源不足:如果后端节点资源(如内存、CPU)耗尽,也可能导致节点无法被分配任务。 - 解决方案:检查后端节点的资源使用情况,释放资源或增加资源。 4. 黑名单问题:引用[1]的错误提到“in black list”,虽然这里的错误没有明确,但可能是由于节点被加入黑名单导致不可用。 - 解决方案:检查是否有节点被加入黑名单,如果有,需要分析被加入黑名单的原因(如频繁失败),解决问题后移除黑名单。 5. 元数据不一致:如果集群的元数据信息不一致,可能导致调度器无法正确分配任务到后端节点。 - 解决方案:检查元数据状态,必要时进行修复。 步骤建议: 1. 首先确认后端节点的状态,使用数据库系统提供的管理命令(如Doris的`SHOW BACKENDS;`)查看节点状态。检查Alive列是否为true,以及是否有错误信息。 2. 如果发现节点宕机,尝试重启该节点。 3. 检查网络连接,确保所有节点之间可以互相通信。 4. 检查系统资源(内存、磁盘、CPU)使用情况,确保没有过载。 5. 查看日志:后端节点的日志可能包含更详细的错误信息,帮助定位问题。 由于具体的数据库系统可能不同(如Doris、TiDB等),上述命令和操作可能有所差异,请根据实际使用的数据库系统进行调整。 注意:引用[2]提供了一些测试数据插入的SQL语句,但与本错误无关,可以忽略。 如果以上步骤仍不能解决问题,需要结合具体的数据库系统版本和日志进行深入排查。 相关问题: 1. 如何检查分布式数据库后端节点的状态? 2. 如何重启分布式数据库的后端节点? 3. 如何查看分布式数据库的日志以诊断问题? 4. 如何解决数据库节点被加入黑名单的问题? </think>### 错误代码 1105 的解决方案 根据您提供的错误信息 `errCode=2 detailMessage=There is no scanNode Backend available.[10059: not alive]`,这是一个典型的分布式数据库后端节点不可用错误。结合引用内容和分布式系统原理,以下是完整的排查步骤和解决方案: #### 核心问题诊断 错误代码 `10059: not alive` 表明: 1. **后端节点故障**:扫描节点(scanNode Backend)宕机或失去响应 2. **连接异常**:网络中断或节点被标记为不可用状态 3. **资源不足**:节点资源(CPU/内存)耗尽导致服务不可用 --- ### 解决方案步骤 #### 第一步:检查后端节点状态 ```sql -- 查看所有BE节点状态(以Doris/StarRocks为例) SHOW BACKENDS\G ``` 重点关注: - `Alive` 字段是否为 `true` - `LastStartTime` 是否最近有更新 - `ErrMsg` 列是否有异常信息[^1] #### 第二步:重启故障节点 ```bash # 登录到对应BE节点进行操作 ./bin/start_be.sh --daemon # 启动BE服务 tail -f log/be.INFO # 查看实时日志 ``` 若节点持续崩溃,检查: - 磁盘空间(`df -h`) - 内存占用(`free -m`) - OOM错误(`dmesg | grep -i kill`) #### 第三步:网络诊断 1. 验证FE-BE连通性: ```bash # 从FE节点执行 telnet <BE_IP> <HEARTBEAT_PORT> # 默认端口 9050 ``` 2. 检查防火墙规则: ```bash iptables -L -n | grep 9050 ``` #### 第四步:黑名单检查(如适用) 若错误日志包含 `in black list`(如引用[1]所示): ```sql SHOW PROC &#39;/backends_blacklist&#39;; ``` 手动移除黑名单: ```sql ADMIN SET FRONTEND CONFIG ("black_list" = ""); ``` #### 第五步:数据分片恢复 当节点长期离线时: ```sql -- 检查数据分片状态 ADMIN SHOW REPLICA STATUS FROM <db_name> PROPERTIES("backendid" = "<故障BE_ID>"); -- 触发自动修复(需Alive节点满足副本数) ADMIN REPAIR TABLE <table_name>; ``` --- ### 预防措施 1. **心跳监控**:配置 `heartbeat_timeout_second` > 网络延迟 2. **资源隔离**:为BE进程设置cgroup限制 3. **高可用架构**: - 部署3个BE节点 - 设置副本数 `replication_num` ≥ 2 ```sql ALTER TABLE <table_name> SET ("replication_num" = "2"); ``` --- ### 典型故障场景分析 | 现象 | 原因 | 解决方案 | |------|------|-----------| | 间歇性报错 | 网络抖动 | 增大 `heartbeat_timeout_second` | | 新增节点不可用 | 端口冲突 | 修改 `be.conf` 中的 `brpc_port` | | 查询时报错 | 数据副本丢失 | 执行 `ADMIN REPAIR` 命令 | | 批量导入失败 | 内存不足 | 调高 `load_process_max_memory_limit_bytes` | > **关键提示**:该错误通常与集群状态相关,需结合 `show proc &#39;/backends&#39;` 和 BE 日志 `log/be.WARNING` 综合分析[^1]。 --- ### 相关问题 1. 如何区分 BE 节点宕机和网络分区故障? 2. 数据副本修复的底层原理是什么? 3. 如何配置分布式数据库的自动化故障转移? 4. 心跳超时参数应该如何优化调整? 5. 哪些监控指标可提前预测节点故障?
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值