Starrocks3.1.13升级到3.2

StarRocks升级文档(存算一体):

前言:
1.Starrocks升级,整体而言比较平滑,支持不停集群滚动升级.由本次经验铺垫,建议后续升级尽量在夜间进行,如此不影响业务方使用.

2.如果要大版本升级(3.x(大版本).xxx),比如从3.1.13升级到3.2,升级路线为:3.1.13--->3.1.max--->3.2目标版本.
不建议跨多个大版本升级,容易导致很多不确定因素.

3.Starrocks升级要注重: 
	1.停掉上游同步程序. 
	2.停掉物化视图.(unactive)
	3.升级时,重点关注  show proc '/statistic'; 中unhealthyTablet是否为0.
	4.show backends;show frontends; 查看升级版本是否出现了版本更替(例如be原来3.1.13,升级后 show backends中看到是3.1.14)
	5.清单方式列举停掉的调度流.
	6.注意先BE,确认每个节点都没有unhealthy tablet,再升级FE(fllower-->leader)
升级流程图:

image-20240830143911116

升级步骤:
step1:备份元数据快照
1.在编译器执行 ALTER SYSTEM CREATE IMAGE 创建新的元数据快照文件.
2.要等元数据同步到其他FE.
 	通过Leader FE节点日志文件fe.log确认元数据快照文件是否推送完成.
 	如果日志打印: “push image.xxx from subdir [] to other nodes. totally xx nodes, push succeeded xx nodes”
	则表示快照文件推送成功.
step2: 关闭Tablet Clone:
ADMIN SET FRONTEND CONFIG ("tablet_sched_max_scheduling_tablets" = "0");
ADMIN SET FRONTEND CONFIG ("tablet_sched_max_balancing_tablets" = "0");
ADMIN SET FRONTEND CONFIG ("disable_balance"="true");
ADMIN SET FRONTEND CONFIG ("disable_colocate_balance"="true");
step3: 升级BE节点:
1.进入BE节点工作路径,停止该节点:
# 将<be_dir> 替换为 BE 节点的部署目录.
cd <be_dir>/be
./bin/stop_be.sh 

2.替换部署文件原有路径 bin 和 lib 为新版本的部署文件。
mv lib lib.bak 
mv bin bin.bak
cp -r /tmp/StarRocks-x.x.x/be/lib  .
cp -r /tmp/StarRocks-x.x.x/be/bin  .

3.启动BE
sh bin/start_be.sh --daemon

4.查看BE是否启动成功:
ps aux | grep starrocks_be

在mysql客户端:
mysql -h 172.16.0.170 -P 9030 -u root -p'xxx'
	show backends\G
	==> 1.Version为升级后版本.
	==> 2.Alive为true.
	==> 3.show proc '/statistic'; (需要关注两个指标:UnhealthyTabletNum和InconsistentTabletNum 都为0才可以升级下一个节点.)
异常Tbalet修复:
step1:
	show proc '/statistic' 找到是否存在不健康的tabelt.

step2:
	SHOW PROC '/statistic/15004'

step3:
	如果出现UnhealthyTabletNum 一直不为0.
	在确定表为3副本的情况下,手动设置副本状态为Bad,然后:
	1.ADMIN SET REPLICA STATUS PROPERTIES ("key" = "value", ...);
		 ADMIN SET REPLICA STATUS PROPERTIES("tablet_id" = "17156", "backend_id" = "10004", "status" = "bad");
	2.ADMIN REPAIR TABLE table_name[ PARTITION (p1,...)]

最后要达到的效果是: UnhealthyTabletNum 必须为0.
升级异常后回滚:
如果升级后BE立刻出现问题,直接在bin中停止当前BE进程,将当前bin和lib重命名为bin.new和lib.new,再将bin.bak和lib.bak改为bin和lib,重新执行bin中的启动脚本可完成回滚.
升级FE步骤:(在升级所有BE后,升级fe follower节点,最后升级Leader节点)
先备份元数据,然后再操作FE.
 cp -r /opt/module/meta /opt/module/meta2203051617(可以带本次操作时间,方便排查)=
1.停止FE节点:
# 将 <fe_dir> 替换为FE节点的部署目录:
cd <fe_dir>/fe
./bin/stop_fe.sh

2.替换文件
mv lib lib.bak 
mv bin bin.bak
mv spark-dpp spark-dpp.bak
cp -r /tmp/StarRocks-x.x.x/fe/lib  .   
cp -r /tmp/StarRocks-x.x.x/fe/bin  .
cp -r /tmp/StarRocks-x.x.x/fe/spark-dpp  .

3.启动新的FE进程:
./bin/start_fe.sh --daemon

4.show frontends; 查看alive状态和fe版本号是否改变.并且show proc '/statistic'; 查看是否unhealthy tablet是否为0

	假设FE出现异常,就需要立刻停止新版本FE进程,重命名新版本的bin和lib为bin.new和lib.new,将旧版本的bin.bak和lib.bak恢复命	  名为bin和lib.然后,删除新版本的元数据目录meta,然后将本分的元数据拷贝一份命名为meta,最后使用老版本的FE程序文件启动.

step6:
	1.在3FE fllower情况下,假设一个FE出现了无法解决的问题,一种应急的做法是立刻停止这个FE进程,清空其元数据目录meta,然后将这个FE视为新实例,指定 --helper 再次添加到新集群.
	2.在升级3 Follower集群,升级前FE会做切主,不需要关注.连接SR客户端可以随意指定FE的ip进行查询或导入.
升级后:
查看FE leader 的 fe.log日志,看是否有异常error日志,如果没有,本次基本升级成功.

1.校验是否可以正常查询,聚合,join.(读正常)
2.启动datax同步脚本,看是否能正常同步数据.(写正常)

升级失败回滚:
step1.每一步都会先使用一个节点升级,一旦出现问题,可以按照之前的回滚操作进行回滚.(单点回滚)

step2.如果集群升级后,有功能异常.(升级前正常的业务系统升级后无法正常运行.)如果不能快速定位就得立刻回滚.(集群回滚) 
	
回滚顺序:
	FE Leader---> FE Follower ---> FE Observer ---> Broker.(和升级顺序完全相反)

FE元数据备份:
	FE回滚前,需要备份一份元数据.

回滚版本:
	一般正常升级,就能正常回滚.
2赞

你很棒棒,给你寄一件贡献者特别版T恤 :sunglasses:

1赞

爱了爱了,姐姐。

你这样别人会以为我跟姐夫@jeff_ding 是 CP :rofl:

哈哈,希望能和社区一起进步,陪社区运营姐姐慢慢变老 :grin:

为什么要备份元数据镜像 ALTER SYSTEM CREATE IMAGE ,直接cp 一份不就行了?

重新生成新的快照啊。然后分发给其他FE节点。这样保证了高可用 FE节点一致性。

异常Tbalet修复:
这里少一步。
step2:
SHOW PROC ‘/statistic/15004’
拿到 tablet_id 之后
step3:
show tablet tablet_id
获取到他的 Detailcmd。
然后执行 Detailcmd 再次获取哪些 backend_id 上有这些 数据块

有了 tablet_id 和 backend_id 之后。
最后才执行
ADMIN SET REPLICA STATUS PROPERTIES(“tablet_id” = “xxxx”, “backend_id” = “xxxx”, “status” = “bad”)

那后面新的元数据不一定一致性,我想表达的是,ALTER SYSTEM CREATE IMAGE后,后面又来了新的元数据,有可能出现不一致了,主要是做升级做这个操作的目的是什么?

我理解是尽可能保证升级前最后一次元数据一致性。
还有就是保证万一出问题,最小程度的保证数据少丢失。
当然这两种情况对这个操作都站不住脚,比较勉强的解释。
真实情况就像你说的,遇到FE出问题该丢还是丢。
还是需要官方的大佬来解释一下。

我的理解是,前面把starrocks服务尽可能停掉,然后再看fe.log无异常,并且显示快照备份success,不就可以做升级了么?为什么要这么纠结呢?

提前做个image,方便回滚

你这个回答应该是正解

回滚从FEleader开始,那是不是意味着,所有的FE都得停啊,不然,关掉了不得重新选个leader出来

回滚这个先停谁都差不多其实。

所有的FE都得停啊

这个不能全停,全停得人工介入才能起来

降级也是从follower开始
回滚应该也是可以参考降级步骤吧
所以这上面写的从leader开始,有点不大理解,因为一停,leader肯定切走了,这样他也不是严格意义上的leader
@许秀不许秀

为什么要停掉其他服务呢?
StarRocks升级是滚动升级,不需要停所有服务的。升级哪个服务停哪个服务就可以了。
群集的滚动升级必然带来的是元数据不一致。
所以这个创建最新快照最多是保留分发一下最新快照。
意义在哪里?

集群滚动升级必然导致元数据不统一。怎么回滚?回滚哪个版本?
跨大版本升级有些元数据存储方式都会变。比如SR2和SR3的元数据存储文件都不同。
我猜测升级follower后,再升级leader,learer会再次把元数据同步一次到follower上。
同步成功并切换成功后才会真正的停止服务。

抱歉,我之前说的不准确,有误.

1.starrocks升级,需要停掉前面相关的数据同步.
2.要停掉物化视图。
3.停掉调度器上的相关starorcks表调度.

滚动升级:
确实是滚动升级,不能全部停掉所有的集群。而是停一个节点然后升级一个节点.

保存快照,是为了在升级出重大问题的时候,短时间解决不了,尽快回退,以降低对业务的印象.