通常来说，若项目上线后业务平稳、集群稳定，能不动系统，就不动系统！不过，StarRocks版本迭代非常迅速，不论从新功能新特性还是从稳定性和查询性能的角度考虑，官方每次发版都有新惊喜，值得我们酌情升级。也是因此，StarRocks历史版本中存在数个变动较大的版本，当我们希望跨大版本升级时，就需要使用几个过渡版本来配合升级。
同样，StarRocks官网对于集群管理的介绍地址为：
一、升级说明整理
结合这两年使用StarRocks的实践经验，将StarRocks的升级/回滚注意事项整理如下表。只要大家注意表格中罗列的事项，升级不会有什么其他的风险：
| 当前版本 | 目标版本 | |||||
| ≤1.17.1 | ≥1.17.2 | ≤1.18.1 | ≥1.18.2 | ≥2.0.0 | ||
| Apache Doris | ≤0.13.11 | 可更新[推荐] | 可更新，无法回滚[不推荐] | 不可更新 | ||
| ≤0.13.15 | 可更新，需修改StarRocks FE源码后单独编译 | 可更新，需修改StarRocks FE源码后单独编译，无法回滚[不推荐] | 不可更新 | |||
| ≥0.14 | 不可更新 | |||||
| StarRocks | ＜1.16.0 | 可升级 | 可升级，无法回滚 | 不可升级 | ||
| ≤1.17.1 | 可升级 | 可升级，无法回滚 | 可升级，务必先全局开启CBO，无法回滚[升级跨度太大，不推荐] | |||
| ≤1.18.1 | 不可回滚 | 可回滚 | 可升级 | 可升级，务必先全局开启CBO | ||
| ≥1.18.2 | 不可回滚 | 可回滚 | 可升级，可回滚 | 可升级，务必先全局开启CBO | ||
| ≥2.0.0 | 不可回滚 | 可回滚[回滚跨度太大，不推荐] | 可升级 | |||
特别说明：
1、StarRocks带有三位的版本号，小版本升级指的是第三位版本，例如2.0.1升级至2.0.2。大版本升级指第二位版本，例如1.19.6升级至2.0.0，或者2.0.1升级至2.1.0。第一位版本是StarRocks里程碑式版本号，也可以同样视为大版本来理解。
2、原则上，每次升级版本跨度不建议超过一个大版本，推荐的升级方式是1.17->1.18，1.18->1.19，1.19->2.0，2.0->2.1等等。现在社区绝大部分同学的版本都不会低于1.16，这里提供一种我实践多次未出现问题的升级路线，即1.16.#->1.17.1->1.17.9->1.19.6->2.0，仅供大家参考，相关版本可私信我或在社区联系StarRocks官方同学获取。
3、StarRocks 2.0.0之前的版本升级至2.#版本时，务必先全局开启CBO。因1.16之前的版本无CBO优化器，所以不要直接升级，可能会出现无法预测的问题。
4、基于Apache版本更新时，推荐修改配置文件后全量替换安装包；StarRocks小版本升级时，推荐替换整个lib目录；大版本升级时，推荐同时替换bin和lib目录。小版本升级时之所以建议整个替换lib，而不是只替换其中的starrocks-fe.jar和starrocks_be，是因为某些小版本也同时升级了其他依赖，为避免引起冲突，整个替换lib目录是较为稳妥的。同样，若不确定当前版本到目标版本是否为大版本升级时，修改配置文件后全量替换安装包也是非常稳妥的方案。
5、Apache Doris/百度Palo需更新至StarRocks时，推荐的方式为先升级至Apache Doris 0.13.11，然后更新至StarRocks 1.17.1，再进行后续升级。
二、升级说明及可能的异常处理
我本地测试环境的三台机器当前是2.0.1版本，咱们就以它为例，将其升级为2.1.1版本。新版本的安装包可以从官网直接获取，官方下载地址：
StarRocks - 新一代极速全场景MPP数据库
https://www.starrocks.com/zh-CN/download/community
在官网复制具体的安装包链接后可在服务器上使用wget命令下载：
[root@node01 software]# wget https://www.starrocks.com/zh-CN/download/request-download/15 -O StarRocks-2.1.1.tar.gz
下载后校验MD5码，确认文件无损坏：
[root@node01 software]# md5sum StarRocks-2.1.1.tar.gz
103f189dfbd043683933012a0e1d6c18 StarRocks-2.1.1.tar.gz
2.1、升级前的思考
“升级有风险，操作需谨慎”，这可能都是运维同学的口头禅了，为了尽可能的规避风险，大家在对生产环境进行升级时，除了错开业务高峰时间，不妨也按照这里咱们梳理的步骤“三思而后行”。
2.1.1 确认升级前后版本
根据前面整理的升级说明表，2.0.1升级至2.1.1属于大版本升级，跨度仅为1个大版本，这样就没有其他特别的注意事项，可以正常升级。
假设，我们当前的集群版本是1.17.1，想要升级到的版本是2.1.1。参考前面的表格，当前版本是≤1.17.1，目标版本≥2.0.0，行列相交对应的单元格内容为“可升级，务必先全局开启CBO，无法回滚[升级跨度太大，不推荐]”，看到“不推荐”后，如果是生产环境，我们就要规避风险，不要直接升级，而是逐个大版本的过渡升级。
不久前，社区有同学尝试直接从1.16升级到了1.19.6，结果升级后出现了多个奇怪的报错，例如Vectorized engine not support unknown child type cast，且无法正常回滚。向社区求助后，StarRocks DBA同学排查定位到是几个在1.16中没有但在1.19.6版本需要开启或关闭的参数在升级过程中没有办法自动生效，又在1.19.6中单独配置了一次集群才恢复正常。
社区也有同学曾尝试从1.15直接升级2.0版本，发现升级时BE是根本起不来的，无奈只能将该BE节点DROP掉，利用三副本的特性让集群自己恢复丢失数据。
相信大家都是爱好世界和平的，在没有多次实践检验的前提下，咱们一次一个大版本，慢慢迭代升级，慢是慢了些，但最为稳妥。
2.1.2 确认升级顺序
StarRocks保证BE后向兼容FE，即新版本的BE可以兼容老版本的FE，所以我们升级时要严格按照：BE->FE Observer->FE Follower->FE Leader->Broker来进行。
具体来说，首先逐个升级BE，升级一个后观察几分钟，集群没有异常且没有不健康的tablet即可升级下一个。通常，我们不建议也没有必要在升级一个BE后观察数小时甚至数天才继续升级，这样不同版本的BE在一个集群内长时间运行反而可能会出现问题。从1.18版本后，升级或者回滚其实并没有什么风险，大家放心大胆操作，只要不是一些低级错误的操作，StarRocks没有那么脆弱。
BE全部升级完成后，同样观察几分钟，就可以升级FE。为了方便理解，不细究定义，就认为FE有三类角色：Leader、Follower和Observer，它们的升级顺序为Observer->Follower->Leader，依旧是逐个进行。如果集群中是1 Leader+多Observer的架构，同样也是先逐个升级Observer，再升级Leader。升级每个FE前，务必注意先在本地备份一份元数据（即整个meta目录），这个至关主要！假设出现不可逆问题，这份元数据可能就是救命的稻草。每个FE升级后，查看其状态，观察几分钟，只要Alive为true，即可进行后续的升级。
在FE和BE正常升级完成后，咱们就可以喘口气了，剩下的Broker作为和HDFS类交互的插件，它的升级没有什么风险，但是我们也务必注意将其升级到和咱们FE、BE的主程序版本一致，不然在进行Broker Load等操作时，可能因为版本不一致出现一些看不太懂的问题。
2.1.3 确认升级影响
不考虑升级操作自身的风险，StarRocks的升级我们可以从以下两个角度思考风险和影响：
1）功能变化影响
新版本会不会有一些功能变化导致升级后原有业务受到影响的？比如导入参数名称的改变、SQL语法的修改等等，这部分确实是有一些的。
例如StarRocks 1.18.2版本取消了Broker Load的exec_mem_limit参数，改用load_mem_limit，或者2.0版本后无缓存删除的语法改为drop table tbl force，再或者2.0独有的tablet_max_versions=1000的限制等等。
如果我们是从Apache Doris更新过来，可能还有其他的语法需要注意，例如Apache Doris 0.13版本中，string是等于varchar(1)，其Routine Load任务中允许字段重名而StarRocks不允许等等。
这些功能变化我们是没有办法完全的整理罗列的，最好的方案就是我们先在测试环境进行充分的测试验证后再对生产环境进行升级。
2）升级过程影响
因为升级过程中我们不可避免的要停止原有进程和启动新进程，所以大家一直比较关注升级过程中能不能做到上层业务的无感知。
结论是：多FE多BE的三副本集群，在整个升级过程中，查询通常不会受到影响，导入可能会受到影响（原子性），Schema Change操作可能受到影响，Routine Load例行导入任务个别可能受到影响。
2.2 集群升级
“三思”之后，真正的升级操作反而不复杂了。先将安装包分发至各个节点，当前StarRocks 2.0.1的集群正常运行，以node01节点为例（三台服务器部署路径相同），原部署路径为：
| 服务名称 | 原版本 | 相关路径 |
| FE | 2.0.1 | 部署目录：/opt/module/starrocks/fe 元数据目录：/opt/module/meta |
| BE | 2.0.1 | 部署目录：/opt/module/starrocks/be 数据目录：/opt/module/storage |
| Broker | 2.0.1 | /opt/module/starrocks/apache_hdfs_broker |
下载好的2.1.1的安装包位于：/opt/software/StarRocks-2.1.1.tar.gz
2.2.1 升级BE
因为要进行大版本升级，我们需要替换bin和lib，首先重命名BE的bin和lib目录：
[root@node01 ~]# cd /opt/module/starrocks/be
[root@node01 be]# mv bin bin.bak
[root@node01 be]# mv lib lib.bak
解压安装包，并分发新版本的文件到be的目录中：
[root@node01 be]# cd /opt/software/
[root@node01 software]# tar xvf StarRocks-2.1.1.tar.gz
[root@node01 software]# cp -r StarRocks-2.1.1/be/bin /opt/module/starrocks/be/
[root@node01 software]# cp -r StarRocks-2.1.1/be/lib /opt/module/starrocks/be/
注意这里一定不要不重命名原目录直接覆盖，这可能会导致该目录中存在同一个jar包两个不同版本，引发冲突造成不可控的报错。
切换至BE部署目录：
[root@node01 software]# cd /opt/module/starrocks/be/
观察目录结构：
[root@node01 be]# ll
total 0
drwxr-xr-x 2 root root 106 Mar 5 14:36 bin
drwxr-xr-x 2 root root 120 Mar 4 19:54 bin.bak
drwxr-xr-x 2 1007 1007 42 Dec 17 12:21 conf
drwxr-xr-x 4 root root 79 Mar 5 14:37 lib
drwxr-xr-x 7 root root 99 Feb 17 15:53 lib.bak
drwxr-xr-x 2 root root 126 Dec 2 09:37 log
drwxr-xr-x 3 1007 1007 244 Nov 29 21:32 www
停止bin.bak目录下的进程，启动新bin目录下的新BE进程：
[root@node01 be]# ./bin.bak/stop_be.sh
stop starrocks_be, and remove pid file.
[root@node01 be]# ./bin/start_be.sh --daemon
访问StarRocks，查看该BE状态：
[root@node01 be]# mysql -h127.0.0.1 -P9030 -uroot -proot
……
mysql> show backends\G
*************************** 1. row ***************************
BackendId: 10002
Cluster: default_cluster
IP: 192.168.110.101
HeartbeatPort: 9050
BePort: 9060
HttpPort: 8040
BrpcPort: 8060
LastStartTime: 2022-03-05 14:42:20
LastHeartbeat: 2022-03-05 14:44:20
Alive: true
SystemDecommissioned: false
ClusterDecommissioned: false
TabletNum: 13445
DataUsedCapacity: 376.222 MB
AvailCapacity: 18.408 GB
TotalCapacity: 37.017 GB
UsedPct: 50.27 %
MaxDiskUsedPct: 50.27 %
ErrMsg:
Version: 2.1.1-cdbe41b
Status: {"lastSuccessReportTabletsTime":"2022-03-05 14:44:20"}
DataTotalCapacity: 18.775 GB
DataUsedPct: 1.96 %
查看到Version已经是2.1.1-cdbe41b，Alive也为true后，基本是没什么问题的，但我们先不要着急立刻升级下一个节点，比较稳妥的方案是检查一下当前集群的副本健康情况，执行SQL命令：
mysql> show proc '/statistic';
我们需要关注两个指标：UnhealthyTabletNum和InconsistentTabletNum。
UnhealthyTabletNum代表当前集群中不健康的tablet个数，InconsistentTabletNum表示集群中数据不一致的tablet个数。状态不健康大家好理解，解释一下副本不一致。我们建表时经常提到默认是三副本，这个三副本，其实就是说StarRocks表中的数据经过分区分桶后形成的tablet保存了几份，三副本就是三份。一个tablet的三个副本中的数据理论上是完全一致的，但总有一些特殊的情况比如导入过于频繁、网络异常、IO异常等原因导致它们内部的数据不太一样，此时就会被标记为Inconsistent。同样，一个tablet的三个副本中如果有哪个出现了损坏，那这个tablet也会被标记为Unhealthy。StarRocks后台常驻进程会不断的检查和修复不健康或者不一致的副本，所以每升级完一个BE，我们都需要执行这个命令，来观察这两项指标，确认都为0后，再进行下一个BE的升级。
对InconsistentTabletNum这个指标还需要特别说明一下，当前的版本对该指标的统计可能是不太准确的，这里请教过了StarRocks的研发老大们，如果发现InconsistentTabletNum中有较大的数值且一直没有减少，目前可以先不用在意，通常并不是真的副本不一致，可以正常升级。
而如果UnhealthyTabletNum一直存在数值没有归零，就说明因为某些原因，集群没有修复或者没能优先修复异常的tablet，我们可能就需要手动调整对应库表的修复优先级，再或者找到有问题的tablet，将其状态手动置为Bad，让集群直接对其优先修复。手动设置副本状态为Bad的这个操作需要特别注意，操作前务必确认当前集群中这个tablet是有可用副本的，也就是说对应的表至少是2副本或者3副本的表，不然单副本下，tablet一旦损坏，或者是我们手动将其状态置为了Bad，数据就是真的丢失了。
优先修复指定的表或分区的语法为：
ADMIN REPAIR TABLE table_name[ PARTITION (p1,...)]
可以通过以下命令取消优先级：
ADMIN CANCEL REPAIR TABLE tbl [PARTITION (p1, p2, ...)];
参考地址：
手动设置指定副本状态语法为：
ADMIN SET REPLICA STATUS PROPERTIES ("key" = "value", ...);
参考地址：
假设我们前面发现starrocks库对应的行中有1个不健康的副本一直未被修复，我们可以根据starrocks库对应的DbId 15004查看到具体的tablet编号，查看命令为：
mysql> SHOW PROC '/statistic/15004';
这里假设我们看到的TabletID为17156，就可以进一步查看到这个tablet对应的库表和分区信息：
mysql> show tablet 17156\G
*************************** 1. row ***************************
DbName: default_cluster:starrocks
TableName: sales
PartitionName: sales
IndexName: sales
DbId: 15004
TableId: 17122
PartitionId: 17121
IndexId: 17123
IsSync: true
DetailCmd: SHOW PROC '/dbs/15004/17122/partitions/17121/17123/17156';
此时我们就可以通过设置修复优先级的方式让这个表优先修复。
同时，我们也可以继续执行上面的DetailCmd命令，来查看这个tablet的三个副本信息，看看是哪个副本不正常：
mysql> SHOW PROC '/dbs/15004/17122/partitions/17121/17123/17156'\G
*************************** 1. row ***************************
ReplicaId: 17157
BackendId: 10004
Version: 3
VersionHash: 6249749078520901728
LstSuccessVersion: 3
LstSuccessVersionHash: 6249749078520901728
LstFailedVersion: -1
LstFailedVersionHash: 0
LstFailedTime: NULL
SchemaHash: 7136400
DataSize: 562
RowCount: 1
State: NORMAL
IsBad: false
VersionCount: 1
PathHash: -599837224777914539
MetaUrl: http://192.168.110.103:8040/api/meta/header/17156/7136400
CompactionStatus: http://192.168.110.103:8040/api/compaction/show?tablet_id=17156&schema_hash=7136400
返回值较长，咱们以一个为例，假设它的IsBad属性为true，我们就可以根据前文的信息，提取TabletID和BackendId来将这个副本的状态置为Bad，加速其修复：
mysql> ADMIN SET REPLICA STATUS PROPERTIES("tablet_id" = "17156", "backend_id" = "10004", "status" = "bad");
因为这个副本原本是正常的，执行后，我们再执行：
mysql> show proc '/statistic';
发现已经有了一个不健康的tablet，根据集群繁忙程度及副本大小，等待数秒或数分钟，会发现已修复完成，UnhealthyTabletNum恢复为0。
若升级后BE立刻出现问题，直接在bin中停止当前BE进程，将当前的bin和lib重命名为bin.new和lib.new，再将bin.bak和lib.bak改回bin和lib，然后重新执行bin中的启动脚本即可完成回滚。
2.2.2 升级FE
如果说升级BE主要需要注意数据问题，升级FE注意的就是元数据。使用show frontends;命令查看当前集群，确认Leader为node02，另外两个为Follower，那我们就以node03演示。
先将原程序目录重命名：
[root@node03 ~]# cd /opt/module/starrocks/fe/
[root@node03 fe]# mv bin bin.bak
[root@node03 fe]# mv lib lib.bak
从node01复制2.1.1的FE文件到该目录下：
[root@node01 fe]# pwd
/opt/software/StarRocks-2.1.1/fe
[root@node01 fe]# scp -r bin node03:/opt/module/starrocks/fe/
[root@node01 fe]# scp -r lib node03:/opt/module/starrocks/fe/
回到node03，查看当前目录情况：
[root@node03 fe]# ll
total 36
drwxr-xr-x 2 root root 86 Mar 5 16:14 bin
drwxr-xr-x 2 root root 100 Mar 4 19:54 bin.bak
drwxr-xr-x 2 1007 1007 42 Dec 2 15:56 conf
drwxr-xr-x 2 root root 12288 Mar 5 16:14 lib
drwxr-xr-x 2 root root 12288 Feb 17 15:52 lib.bak
drwxr-xr-x 2 root root 4096 Mar 5 00:00 log
drwxr-xr-x 3 root root 48 Mar 4 20:16 plugins
drwxr-xr-x 2 1007 1007 55 Nov 29 21:32 spark-dpp
drwxr-xr-x 4 1007 1007 30 Nov 29 21:32 webroot
停止原FE进程：
[root@node03 fe]# ./bin.bak/stop_fe.sh
waiting fe to stop, pid: 72852
stop java, and remove pid file.
备份元数据目录[重要]：
[root@node03 fe]# cp -r /opt/module/meta /opt/module/meta2203051617
备份元数据时务必注意带上详细的时间，特殊情况下我们可能会多次备份元数据，一定要分得清每次备份是做了什么操作。
启动新FE进程：
[root@node03 fe]# ./bin/start_fe.sh --daemon
使用show frontends; 命令查看FE状态，观察几分钟，若Alive为true通常就没有问题。
假设FE出现异常，我们需要立刻停止新版本的FE进程，重命名新版本bin和lib为bin.new和lib.new，将旧版本的bin.bak和lib.bak恢复命名为bin和lib。然后，删除新版本程序使用多的元数据目录meta，并将备份的那份元数据拷贝一份命名为meta，最后再使用老版本的FE程序文件启动。这里的操作非常重要，务必要留意。
在3FE Follower的情况下，假设一个FE出现了无法解决的问题，一种应急的做法是立刻停止这个FE的进程，情况其元数据目录meta，然后将这个FE视为新实例，指定--helper再次添加进集群。
在升级3 Follower的集群时，升级前后FE肯定会进行一次切主，这个我们通常不用在意，连接StarRocks的客户端可以随意指定任意FE的IP进行查询或导入，或者我们也可以通过show frontends; 命令，查到IsMaster为true的Leader节点的IP。
2.2.3 升级Broker
升级Broker没有什么风险，只需要保持与FE和BE版本一致即可，以node01节点为例：
[root@node01 ~]# cd /opt/module/starrocks/apache_hdfs_broker/
[root@node01 apache_hdfs_broker]# mv bin bin.bak
[root@node01 apache_hdfs_broker]# mv lib lib.bak
复制程序到该目录下：
[root@node01 ~]# cd /opt/software/StarRocks-2.1.1/apache_hdfs_broker
[root@node01 apache_hdfs_broker]# cp -r bin /opt/module/starrocks/apache_hdfs_broker/
[root@node01 apache_hdfs_broker]# cp -r lib /opt/module/starrocks/apache_hdfs_broker/
查看目录：
[root@node01 apache_hdfs_broker]# ll
total 28
drwxr-xr-x 2 root root 51 Mar 5 16:32 bin
drwxr-xr-x 2 root root 81 Mar 4 19:54 bin.bak
drwxr-xr-x 2 root root 82 Feb 17 15:53 conf
drwxr-xr-x 2 root root 8192 Mar 5 16:32 lib
drwxr-xr-x 2 root root 8192 Feb 17 15:53 lib.bak
drwxr-xr-x 2 root root 4096 Mar 4 18:11 log
停止旧进程，启动新进程：
[root@node01 apache_hdfs_broker]# ./bin.bak/stop_broker.sh
stop java, and remove pid file.
[root@node01 apache_hdfs_broker]# ./bin/start_broker.sh --daemon
Broker没有自带版本号，确认程序是由新程序所在目录启动的即可。
三、回滚说明
在进行前面的升级操作时，我们每一步都会先使用一个节点进行升级，一旦出现问题，我们也介绍了回滚的操作。而在实际业务中，可能还会出现集群整体正常升级完成后，发现有功能异常的问题。直观来说，就是升级前正常的业务系统在升级后无法正常运行了，这种情况下，如果我们不能快速定位到问题原因，就要立刻进行回滚。
回滚操作和咱们升级过程中介绍的相同，只有三个注意事项咱们着重强调：
3.1 回滚顺序
我们已经说过，StarRocks保证BE后向兼容FE，所以回滚的顺序整体和升级相反，为：
FE Leader->FE Follower->FE Observer->BE->Broker
这个顺序也千万不要颠倒。
3.2 备份元数据
FE回滚前，还要务必注意备份一次元数据，我们一定要养成习惯，在对FE进行任何变更前备份一次元数据。
3.3 回滚版本
参考文章开头的表格，正常来说，除了1.17.2之前的版本因为BE RocksDB版本升级问题导致无法回滚之外，其他版本咱们能正常升级上来就能一定能正常回滚回去，大家不用担心。
四、集群扩缩容
广义来说，StarRocks集群的扩缩容包括了增减节点和增减资源。当我们需要为集群增加节点时，建议先参考前面部署环境准备章节对服务器进行调优。
4.1 FE扩缩容
4.1.1 增加FE节点
在增加FE节点前，我们首先注意要添加的机器与原集群在同一个局域网内或者是能够正常通信的。并且，对要该服务器进行时钟同步操作，因为在StarRocks中，当集群FE之间的时钟差大于5秒时是无法正常启动的。
扩容FE的操作可以参考集群部署章节，同新部署时一样，将FE的部署文件分发到对应服务器上，调整配置文件，绑定IP，创建对应的元数据目录，然后首次必需指定一个集群中已存在的FE节点作为helper启动，这样这个FE才不会被当作一个独立的集群。新扩容的FE可以作为Follower或者Observer，实际业务中，我们通常建议扩容为Observer来增加集群的并发读能力。如果扩容为Follower，就要注意所有Follower（包括Leader）的数量要为奇数个。偶数个Follower不是说不能跑，但从容错的角度来说没有什么意义。
以集群中FE为5个Follower为例，按照Follower活过半才能正常选主的原则，当前集群最多允许同时挂2个Follower，挂第3个后，FE整体将不可用。同样的，5个Follower的情况下，也需要最少启动3个FE后，FE才能正常选主，不然FE就会一直打类似“notify new FE type transfer: UNKNOWN”的日志，始终无法启动。若以集群中FE为4个Follower为例，仍按照过半才可选主的原则，最多允许挂1个FE，当同时挂2个Follower后，集群就不可用了。
通常来说，集群中有1个或3个Follower就可以了，当扩容时都建议扩容为Observer，Observer不参与选主，也没有写元数据的能力，即便Follower都不可用的情况下，Observer仍旧可以保证集群对外提供读的能力。
逻辑讲完，就是语法，StarRocks扩容命令都是一句SQL，扩容FE的语法为：
alter system add follower "fe_host:edit_log_port";
alter system add observer "fe_host:edit_log_port";
4.1.2 删除FE节点
若业务高峰期过后需要缩容FE，同意需要考虑上面选主的问题，不再赘述，删除语法为：
alter system drop follower "fe_host:edit_log_port";
alter system drop observer "fe_host:edit_log_port";
这里注意，在集群中删除FE后，只是说将该FE与集群解耦，并不会同步删除其存在本地磁盘的元数据和部署文件，若确认不需要后，可以手动清理。
4.1.3 增加FE内存
FE另一个需要注意扩容的就是内存，在fe.conf中，有一个配置堆内存的参数：
默认大小是8G，在实际业务中，我们通常建议将其设置为20G或更大。我们知道FE是Java语言开发的，将堆内存设置大除了能避免Full GC外，还有一个重要的原因是FE的元数据是全内存的，且FE隔段时间就会触发Checkpoint，默认情况下，如果JVM内存使用率超过60%，FE就会停止生成元数据的Checkpoint，防止OOM，这样就会让meta/bdb目录一直变大，导致FE重启时非常非常慢。
扩展FE内存的方法就是在JAVA_OPTS中设置给一个较大的合适的内存，然后重启FE生效。如果服务器内存有限，一定要关注bdb目录的大小已经meta/image目录中镜像的生成时间，当发现bdb目录始终超过数G后且image文件很多天没有更新后，就要及时对机器扩容，然后调整这里的参数。
4.2 BE扩缩容
4.2.1 增加BE节点
当集群算力不足以满足业务需求时，扩容BE是最直接的选择。扩容BE同样与新部署时相同，先修改be.conf中相关的配置文件，绑定IP，设置数据存储目录并在本地创建对应的目录。然后启动该BE后，在StarRocks中将其添加进集群：
alter system add backend 'be_host:be_heartbeat_service_port';
4.2.2 缩容BE节点
缩容BE有两种方式：DROP和DECOMMISSION。
DROP会立刻删除BE节点，丢失的副本由FE调度补齐；DECOMMISSION先保证副本补齐，然后再下掉BE节点。DECOMMISSION方式更加友好，生产上建议采用这种方式。
二者的命令类似：
alter system decommission backend "be_host:be_heartbeat_service_port";
alter system drop backend "be_host:be_heartbeat_service_port";
Drop backend是一个危险操作所以需要二次确认后执行，在2.1版本中，如果集群中有单副本的表，直接执行Drop也会报错，提示存在数据丢失风险，如果需要强制删除，语法为：
ALTER SYSTEM DROP BACKEND 'be_host:be_heartbeat_service_port' FORCE;
在使用DECOMMISSION缩容时，我们通过show backends命令查看下线节点的tabletNum发现会逐渐减少迁移到其他节点，但有时会发现tabletNum下降到一定数值后就不变化，导致该节点始终无法下线。这种情况，那些tablet通常是属于刚被删除的表、分区或物化视图，而刚被删除的对象会保留在回收站中，下线逻辑不会处理这些分片。这时可以通过修改FE的配置参数catalog_trash_expire_second来修改对象在回收站中驻留的时间，默认为1天（86400秒），当对象从回收站中被删除后，这些tablet就会被处理了。也或者可以通过show proc "/statistic";命令查看集群是否还有unhealthy的tablet，如果为0，则可以直接通过drop backend语句删除这个BE。
4.2.3 增加BE磁盘
当数据量很大时，我们就需要拓展BE的存储磁盘，为BE节点所在的服务器增加磁盘后，我们首先需要在be.conf中添加该磁盘上的存储目录，例如：
storage_root_path = /data1/storage;/data2/storage;/data3/storage
其中/data1、/data2、/data3分属三块不同的磁盘。配置完成后，再重启BE即可完成扩容。
还有一点需要注意，当前StarRocks是会进行节点内不同磁盘间的数据均衡的，目前磁盘均衡的标准是磁盘使用百分比，如果希望有较好的均衡效果，推荐在扩容时使用多块容量相同的磁盘。
4.3 Broker扩缩容
4.3.1 增加Broker节点
Broker的数量通常与BE节点数保持一致，Broker不会占用多少资源，所以建议和BE直接混布在相同的机器上以减少不必要的带宽传输。
Broker节点不需要绑定IP，增加Broker时同部署章节一样，直接启动Broker进程，然后添加进集群即可，添加Broker的写法为：
ALTER SYSTEM ADD BROKER broker_name "broker_host:broker_ipc_port";
通常建议将集群中所有的broker_name设置为相同的名称，这样在进行Broker Load等作业时，可以并行的调用多个Broker进程来处理各自节点的数据。
4.3.2 缩减Broker节点
缩减语法为：
ALTER SYSTEM DROP BROKER broker_name "broker_host:broker_ipc_port";
4.4 扩缩容影响
在前期调研阶段，其实我们已经对StarRocks集群进行了一系列例如FE BE断网、断电、杀进程、增减节点等等的非功能测试来观察这些突发情况对上层业务的影响，最终结论是都不会影响StarRocks的查询功能，所以大家放心扩缩容，安心大胆的使用。
1309
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
