Starrocks集群的规划以及高可用测试
首先是集群的规划
这里是准备部署实际的生产集群，首先是FE部署的建议
是建议至少部署三台FE 节点，以防止单点故障。
这样至少能保证一台FE掉线的情况下对外提供服务，因为规则为
Leader FE 节点掉线，只要超过半数的 Follower FE 节点存活，StarRocks 就会重新选举出一个新的 Leader FE 节点。
所以我们采用一个AutoScaling组来进行管理，三个FE机器
每台分配 8 个 CPU 内核和 16 GB RAM，100 GB 的 HDD 存储。
而对于BE部署的建议
这里至少大于三台BE节点，防止至少一台出现问题的时候从而全局不能使用
所以我们采用一个AutoScaling组来进行管理，六个FE机器
每台分配16 个 CPU 内核和 64 GB RAM。
至于存储，我这里是根据公式按照现有数据存储大小进行规划
|
BE 节点所需的总存储空间 = 原始数据大小 * 数据副本数/数据压缩算法压缩比
原始数据大小 = 单行数据大小 * 总数据行数 |
(6.1GB + 749.1GB) * 3 replicas / 3 Snappy = 755GB
为了方便提供冗余，再额外增加500GB,
故六台BE节点，每台210GB SSD
对于集群FE的部署，由于我们只有三台FE，故不设立Observer节点提高FE的读写
新增FE命令
bin/start_fe.sh –helper “fe_leader_host:edit_log_port” –daemon
删除FE命令
ALTER SYSTEM DROP follower “fe_host:edit_log_port”;
FE的负载均衡由ProxySQL提供
https://docs.starrocks.io/zh-cn/latest/administration/Load_balance
其次是BE
新增BE命令
ALTER SYSTEM ADD backend ‘be_host:be_heartbeat_service_port’;
缩容则是有两种方式
ALTER SYSTEM DROP backend “be_host:be_heartbeat_service_port”;
这种模式会立刻删除BE，其中的副本如果在其他主机不存在则丢失，如果存在则会后来慢慢同步
ALTER SYSTEM DECOMMISSION backend “be_host:be_heartbeat_service_port”;
而 DECOMMISSION 先保证副本补齐，然后再删除 BE 节点
对于BE的扩容，官网没有直接说如何将新添加的volumn挂载进BE
这里我们做一个测试
BE的副本均衡，由于我们一般导入表的时候都是多副本存储，可能存在某天高负载的BE节点需要向低负载的BE节点同步
首先在低负载的节点上创建一个副本，然后再删除这些分片在高负载节点上的副本。
而自动的负载的触发，会利用磁盘使用率 和 副本数量 两个指标，为每个 BE 计算得出一个 loadScore，作为 BE 的负载分数。分数越高，表示该 BE 的负载越重。TabletScheduler 会每隔 1 分钟更新一次 CLS。
而且为了避免同一台 BE 同一时间执行过多的任务，从而出现较大的 IO 压力。默认为每块置两个 slot 用于副本修复。避免过大负载
接下来我们来做些实验
首先部署一个三BE集群并导入数据，之后再加一台BE，此时新的BE数据为空
然后断开一个老节点，查看数据是否同步
触发了修复任务
在断开的时候，数据能正常访问
之后上线老节点
并没有同步回来
其次是导入数据的时候出现节点下线
会失败，errmsg为
type:LOAD_RUN_FAIL; msg:Backend node not found. Check if any backend node is down.