Starrocks集群运维

4.1 集群升级与降级
    集群升降级操作的语法为
#cluster_name：需要升降级的集群名，例如现在使用的'sr-c1'
#target_version：升降级的目标版本，规范写法同样为"v+版本号"，例如使用的'v3.0.1'
./stargo cluster upgrade|downgrade <cluster_name> <target_version>
    也可以指定集群的某个实例，进行升降级。
#node_id：即上文通过display命令查到的ID列
./stargo cluster upgrade|downgrade <cluster_name> <target_version> --node <node_id>
备注：
1>    StarRocks 非常不推荐进行跨大版本的升降级(例如 2.1-2.5或 2.4-3.0，亦或者反向)。
2>    目前在进行升级或降级操作时，没有自动进行集群副本状态的校验。当集群建表都为默认的三副本时，我们只需要在升降级前执行show proc '/statistic';命令，确认 UnhealthyTabletNum为 0后，即可进行升降级操作。
3>    若之前指定了某个实例进行了升级，在后续进行完整的集群升级时，该实例仍会被视为普通节点再按照升级流程进行一次。
4.1.1 集群升级
对佛山测试环境Starrocks集群进行升级，从3.1.6升级到3.1.8版本。
4.1.1.1 使用StarGo部署工具升级集群
4.1.1.1.1 Starrocks集群升级3.1.6->3.1.8
当需要对集群进行升级操作时，我们需要配置repo.yaml，当前将StarRocks集群从3.1.6升级至3.1.8版本。
#修改repo.yaml
#该配置文件配置部署或升级/降级需用的StarRocks二进制包路径及包名
sr_path: /usr/local/apps/
#sr_name: StarRocks-3.1.6.tar.gz
sr_name: StarRocks-3.1.8.tar.gz
 
 
备注：
1>    在升级前我们仍需要先下载StarRocks对应版本的二进制包，例如当前升为3.1.8版本的部署包已下载存放至/usr/local/apps目录中。
2>    升级或降级操作不会依赖部署时配置的deploy-template.yaml文件，我们仅需要配repo.yaml以获取目标版本的安装包。
    升级前查看当前集群信息和状态
./stargo cluster display sr-cluster
./stargo cluster status sr-cluster
 
 
 
说明：升级前，当前集群状态正常，版本号3.1.6。
    执行升级命令
./stargo cluster upgrade sr-cluster v3.1.8
执行升级命令后，StarGo会拉取repo.yaml 中配置的本地安装包到工作目录解压，然后逐个将原版本程序的bin和lib目录添加时间戳重命名，例如：bin.bak-20230614125225，再将新版本程序的bin文件夹和lib文件夹分发到目标目录，最后将进程切换到新版本程序。
升级的整体顺序为 BE-->FE-->Broker，在控制台打印的日志中我们可以看到程序执行的详细步骤。
注意：每次升级后，原程序的bin目录和lib目录都会在程序部署目录中备份，出于安全角度设计，StarGo不会删除这些文件。在确认不需要后，我们可以手动进行清理，避免不必要的磁盘空间占用。
 
 
[2024-03-28 16:30:02.763039  OUTPUT] Starting upgrade BE node. [beId = 0]
[2024-03-28 16:30:02.970924    INFO] upgrade BE node - backup BE lib. [host = 172.21.235.212, sourceDir = /opt/starrocks/be/lib, targetDir = /opt/starrocks/be/lib.bak-20240328163002]
[2024-03-28 16:30:41.869499    INFO] upgrade BE node - upload new BE lib. [host = 172.21.235.212, sourceDir = /root/.stargo/download/StarRocks-3.1.8/be/lib, targetDir = /opt/starrocks/be/lib]
[2024-03-28 16:30:41.869687    INFO] Waiting for stoping BE node [BeHost = 172.21.235.212]
[2024-03-28 16:30:43.379528    INFO] upgrade BE node - stop BE node. [host = 172.21.235.212, beDeployDir = /opt/starrocks/be]
[2024-03-28 16:30:43.568483    INFO] upgrade BE node - backup BE bin. [host = 172.21.235.212, sourceDir = /opt/starrocks/be/bin, targetDir = /opt/starrocks/be/bin.bak-20240328163043]
[2024-03-28 16:30:43.910184    INFO] upgrade BE node - upload new BE bin. [host = 172.21.235.212, sourceDir = /root/.stargo/download/StarRocks-3.1.8/be/bin, targetDir = /opt/starrocks/be/bin]
[2024-03-28 16:30:43.999647    INFO] modify start_be.sh 
[2024-03-28 16:30:44.190225    INFO] upgrade BE node - backup JDK. [host = 172.21.235.212, sourceDir = /opt/starrocks/be/jdk, targetDir = /opt/starrocks/be/jdk.bak-20240328163043]
[2024-03-28 16:30:49.751452    INFO] Upload dir JDKSourceDir = [/root/.stargo/download/jdk8u362-b09] to JDKTargetDir = [/opt/starrocks/be/jdk] on BeHost = [172.21.235.212]
[2024-03-28 16:30:50.811067    INFO] upgrade BE node - start BE node. [host = 172.21.235.212, beDeployDir = /opt/starrocks/be]
[2024-03-28 16:31:01.943526    INFO] Waiting for start BE node.[BeHost = 172.21.235.212, Error =  Process exited with status 1
[2024-03-28 16:31:01.943572    INFO] upgrade BE node - start BE node. [host = 172.21.235.212, beDeployDir = /opt/starrocks/be]
[2024-03-28 16:31:13.065480    INFO] Waiting for start BE node.[BeHost = 172.21.235.212, Error =  Process exited with status 1
[2024-03-28 16:31:13.065527    INFO] upgrade BE node - start BE node. [host = 172.21.235.212, beDeployDir = /opt/starrocks/be]
说明：升级失败，看升级信息最后一行显示获取FE信息失败，升级中断。升级流程：是先升级BE节点evoc-sr4  172.21.235.212，停止be，备份lib文件目录，然后上传升级版lib文件目录；再接着是备份bin、jdk，上传bin、jdk，最后重新启动be。
排查：查看be节点log日志目录，没有发现有效信息，没有报错信息。
更新：在询问Stargo社区群后，得知要到stargo_debug.log日志查看升级过程，查找报错信息。
cd /usr/local/apps/stargo-v2.3/
tailf -n 100 stargo_debug.log
 
报错：root用户访问被拒绝
原因是：通过StarGo升级集群中断，是由于fe访问失败，设置过root密码。(默认无密码)
解决办法：使用StarGO升级或是操作集群，如果fe的密码发生过更新，就一定要更新meta.yaml文件中的密码信息。
cd /root/.stargo/cluster/sr-cluster
vim meta.yaml
  
提示：手动方式升级Starrocks集群，用StarGo命令查看集群信息，版本号不会更新为升级后的版本号。
PS：使用StarGo工具对集群进行升级操作等，日志信息要在stargo_debug.log查看。日志路径：/usr/local/apps/stargo-v2.3/

说明：频繁的升降级将会在部署目录产生较多的程序备份，也会在 .stargo/download 目录产生多个版本的安装包及解压文件，当前的逻辑下，我们只能手动清理，后续版本考虑优化。
4.1.1.2 手动操作升级集群
    升级BE节点
上面使用StarGo工具升级失败，接着转手动升级。
先升级3台BE节点，首先停止一台be节点：172.21.235.212这台be节点evoc-sr4。
cd /opt/starrocks/be
./stop_be.sh
 
 
说明：停止这台be节点成功。
#备份文件和上传文件
上传将升级的V3.1.8版本安装包中的bin和lib文件目录到be节点的安装目录：/opt/starrocks/be下。
 
说明：这里由于之前自动升级操作时，已经完成了原集群目录的备份和上传新版集群的目录上去，所以就不用重复再操作备份和上传新版文件的工作了。
#启动该BE节点并查看是否启动成功
sh bin/start_be.sh --daemon
ps aux | grep starrocks_be
 
 
说明：该be节点已完成升级替换包操作，并启动成功。
#再接着操作剩下2台be节点
 
 
 
说明：be节点evoc-sr5和evoc-sr6均已停止。
#备份重启evoc-sr5和evoc-sr6
 
 
 
说明：重启2台be节点成功。
    升级FE节点
升级所有BE 和CN节点后，您可以继续升级FE节点。您必须先升级Follower FE节点，然后再升级Leader FE节点。此集群是存算一体架构部署，故没有CN节点。
#查看当前集群FE节点的角色和状态信息
 
角色LEADER：172.21.235.213  FE节点
角色FOLLOWER：172.21.235.227和172.21.235.202，先升级这两个FE节点。
#进入FE节点工作路径，并停止该节点。
停止FE节点：172.21.235.202
cd /opt/starrocks/fe
./bin/stop_fe.sh
 
 
说明：停止该FE节点成功。
#备份文件和上传文件
替换部署文件原有路径 bin、lib 以及 spark-dpp 为新版本的部署文件
mv lib lib.bak 
mv bin bin.bak
mv spark-dpp spark-dpp.bak
 
#上传文件
cd /usr/local/apps/StarRocks-3.1.8/fe
 
cp -r /usr/local/apps/StarRocks-3.1.8/fe/lib  /opt/starrocks/fe
cp -r /usr/local/apps/StarRocks-3.1.8/fe/bin  /opt/starrocks/fe
cp -r /usr/local/apps/StarRocks-3.1.8/fe/spark-dpp  /opt/starrocks/fe
 
 
说明：上传待升级文件到FE节点部署目录成功。
#启动该FE节点
sh bin/start_fe.sh --daemon
ps aux | grep StarRocksFE
 
 
说明：启动该FE节点成功，继续操作升级下一台FE节点。

#操作升级第二台FE节点
停止FE节点：172.21.235.227
cd /opt/starrocks/fe
./bin/stop_fe.sh
 
 
说明：停止该FE节点成功。
#备份文件和上传文件
替换部署文件原有路径 bin、lib 以及 spark-dpp 为新版本的部署文件
 
说明：备份完成。
#上传文件
cd /usr/local/apps/StarRocks-3.1.8/fe
 
 
说明：上传待升级文件到FE节点部署目录成功。
#启动该FE节点
sh bin/start_fe.sh --daemon
ps aux | grep StarRocksFE
 
说明：启动该FE节点成功。
#操作升级第三台FE节点(角色LEADER)
停止FE节点：172.21.235.213
cd /opt/starrocks/fe
./bin/stop_fe.sh
 
 
说明：停止该FE节点成功。
#备份文件和上传文件
替换部署文件原有路径 bin、lib 以及 spark-dpp 为新版本的部署文件
 
说明：备份完成。
#上传文件
cd /usr/local/apps/StarRocks-3.1.8/fe
 
 
说明：上传待升级文件到FE节点部署目录成功。
#启动该FE节点
sh bin/start_fe.sh --daemon
ps aux | grep StarRocksFE
 
 
说明：启动该FE节点成功。升级三台FE节点和三台BE节点完成。
    查看集群版本升级是否成功
#查看集群信息和集群状态
./stargo cluster display sr-cluster
./stargo cluster status sr-cluster
 
说明：在未更新StarGo的meta.yaml文件中的密码之前，查看集群信息命令，显示fe和be状态为false，版本信息也未显示出来。(但实际通过mysql连接和web界面查看集群fe和be状态是正常的)。说明通过StarGo工具的方式查看和操作集群，一定要注意及时更新它的meta.yaml信息。
cd /root/.stargo/cluster/sr-cluster/
vim meta.yaml
 
 
说明：看集群信息显示：clusterName = sr-cluster   clusterVerison = v3.1.6，meta.yaml文件里的版本号没有变更为升级后的版本。
提示：通过手动方式升级Starrocks集群，用StarGo命令查看集群信息，版本号不会更新为升级后的版本号。需要手动修改meta.yaml文件中的版本号信息。
 
#再次查看集群信息和状态
./stargo cluster display sr-cluster
./stargo cluster status sr-cluster
 
说明：版本信息和状态正常。
#通过连接mysql查看FE信息
 
说明：FE升级重启后，重新选举了LEADER。
#访问集群FE Web界面
账号：root
新密码：evoc@1993
 
#访问集群BE Web界面
http://172.21.235.212:8040/varz
 
#查看starrocks库正常
 
#查看监控
 
 
说明：集群状态正常。
4.1.1.3 升级指定实例(暂未实践)
StarGo支持升级指定实例(这里的实例指具体的某个FE、BE、CN或Broker)，按照上文，升级前也需要下载对应版本的StarRocks二进制包，并修改repo.yaml。
    升级集群sr-c1的FE某节点实例
./stargo cluster upgrade sr-c1 v3.0.1 --node_id 192.168.110.102:9010
4.1.2 集群降级(暂未操作)
对集群进行降级操作时，按照前文，也需要下载对应版本的StarRocks二进制包，并修改repo.yaml，执行降级命令：
./stargo cluster downgrade sr-c1 v2.5.6
说明：频繁的升降级将会在部署目录产生较多的程序备份，也会在.stargo/download目录产生多个版本的安装包及解压文件，当前的逻辑下，我们只能手动清理，后续版本考虑优化。
4.1.2.1 降级指定实例
StarGo支持降级指定实例(这里的实例指具体的某个 FE、BE、CN 或 Broker)，降级前还是需要下载对应版本的StarRocks二进制包，并修改repo.yaml。
    例如降级集群sr-c1的BE某节点实例
./stargo cluster downgrade sr-c1 v2.5.6 --node_id 192.168.110.102:9060
4.2 集群扩容与缩容
4.2.1 集群扩容
stargo中的“集群扩容”是指集群的“横向扩容”，即为原有的集群增加FE、BE 或 Broker节点。
    集群扩容的语法
#cluster_name：需扩容集群的集群名，例如这里的'sr-c1'。
#topology_file：包含扩容节点对应信息的yaml拓扑文件，文件名称随意，stargo通过该文件获取扩容节点的ip、端口及目录信息。
./stargo cluster scale-out <cluster_name> <topology_file>
说明：扩容的yaml文件中只需要配置需扩容节点相关的信息，不需要也不能填写已有集群的信息。
扩容的yaml不需要编写global中的信息，这部分会直接沿用原集群的信息。其它信息参考部署时的模板文件填入即可，例如新建一个yarm文件命为sr-out.yaml：
be_servers:
- host: 172.21.228.xx
ssh_port: 22
be_port: 9060
webserver_port: 8045
heartbeat_service_port: 9050
brpc_port: 8060
deploy_dir : /opt/starrocks/be
storage_dir: /data/starrocks/be/storage
log_dir: /data/starrocks/be/log
priority_networks: 172.21.228.xx
config:
mem_limit: 80%
在执行扩容命令前，我们仍需在目标服务器上手动创建对应的目录，并配置stargo所在节点对目标节点的免密。
    根据我们配置的拓扑文件，执行扩容命令：
./stargo cluster scale-out sr-c1 sr-out.yaml
4.2.2 集群缩容(暂未操作)
stargo中的集群缩容仍是指横向缩容，即将集群中的某个节点在集群中删除。对于FE、CN和Broker实例，stargo会直接执行Drop命令，该命令为同步操作，执行后对应节点即完成缩容。而对于BE实例，基于数据安全考虑，stargo会执行DECOMMISSION命令，该命令为异步操作，需等待目标BE将自己的数据迁移至集群其他节点后才会脱离集群完成缩容，所以实际的缩容时间会随该节点数据量的增大而增加。
说明：
1>    FE Leader节点不允许缩容，可以先停止其服务待集群重新选主后再执行缩容。
2>    BE是否被执行缩容可通过show backends;命令返回值中的SystemDecommissioned是否为true来判断。在BE开始缩容后，其上的tablet会自动迁移至集群其他节点，故BE的缩容进度可通过返回值中的TabletNum剩余数来粗估。
3>    因DECOMMISSION为异步操作，stargo仅会在执行缩容命令后给出提示，并不会一直等待缩容完成。若发现集群缩容一直未完成，在确认集群中表都为三副本且集群中没有不健康副本后，可在StarRocks中对该BE再次执行drop命令。
    集群缩容的语法为
#cluster_name：需缩容的集群名称
#nodeId：缩容节点的节点ID，即为通过display命令查到的ID字段值。
./stargo cluster scale-in <cluster_name> --node <nodeId>
#例如我们先查看集群的节点 ID
cd /usr/local/apps/stargo-v2.1/
./stargo cluster display sr-c1
 
#根据节点ID，例如对85节点的 FE进行缩容操作
./stargo cluster scale-in sr-c1 --node 172.21.228.85:9010
#再演示对 85节点的BE进行缩容操作
./stargo cluster scale-in sr-c1 --node 172.21.228.85:9010
提示：其他实例的缩容可参考上文，此处不再演示。
4.2.3 取消缩容(暂未操作)
    集群取消缩容的语法
#cluster_name：要取消缩容的集群名称
#nodeId：要取消缩容的节点ID
./stargo cluster s1-c1 sr-c1 --node <nodeId>
例如上文BE的缩容操作，若我们在执行缩容操作后，在缩容未完成前想取消缩容，即可执行如下命令：
./stargo cluster cancel-scale-in sr-c1 --node 172.21.228.85:9060
注意：取消缩容的操作只针对BE服务。
4.3 备份恢复(存算分离架构)
备份(backup)操作是指将指定表或分区的数据，直接以StarRocks存储的文件的形式，上传到远端仓库中进行存储。
同一数据库下只能有一个正在执行的BACKUP或RESTORE任务，也即当前可以认为集群中同时只能进行一个备份或者还原的任务。
4.3.1 备份数据到远端存储
创建REPOSITORY远端仓库
4.3.1.1 先在hdfs文件系统创建备份目录并赋予读写权限
mkdir -p /repo_dir/backup
sudo -su hdfs hdfs dfs -chmod -R 777 /repo_dir/backup
 4.3.1.2 通过CREATE REPOSITORY创建远端仓库
CREATE REPOSITORY hdfs_repo
WITH BROKER
ON LOCATION "hdfs://172.21.228.77:8020/repo_dir/backup"
PROPERTIES(
    "username" = "root",
    "password" = "Evoc123$%"
);
 
4.3.1.3 备份
同个数据库，备份只能同时进行一个。
#备份语法
BACKUP SNAPSHOT 数据库名.`自定义快照名`
TO `云端仓库名`
ON (`需备份表名`)
PROPERTIES ("type" = "full");
4.3.1.3.1 全量备份ssb数据库到仓库hdfs_repo中
BACKUP SNAPSHOT ssb.snapshot_ssb
TO hdfs_repo
PROPERTIES ("type" = "full");
4.3.1.3.2 全量备份ssb数据库下的表dates到仓库hdfs_repo中
BACKUP SNAPSHOT ssb.snapshot_dates
TO hdfs_repo
ON (dates)
PROPERTIES ("type" = "full");
#查看已创建的仓库信息
SHOW BACKUP;
 
4.3.1.3.3 全量备份ssb数据库中表dates的分区和表dates到仓库hdfs_repo中
BACKUP SNAPSHOT ssb.snapshot_ssb
TO hdfs_repo
ON(
    dates PARTITION (p1, p2),
    dates
);
4.3.1.4 查看备份
    查看仓库hdfs_repo中已有的备份
#语法
SHOW SNAPSHOT ON <repo_name>
[WHERE SNAPSHOT = <snapshot_name> [AND TIMESTAMP = <backup_timestamp>]]
#参数说明
repo_name：备份所属仓库名
snapshot_nam：备份名
backup_timestamp：备份时间戳
#实操
SHOW SNAPSHOT ON hdfs_repo;
 
    查看仓库hdfs_repo中名为backup1的备份
SHOW SNAPSHOT ON example_repo
WHERE SNAPSHOT = "backup1";
    查看仓库hdfs_repo中名为backup1、时间戳为2023-07-11-15-56-46-916的备份
SHOW SNAPSHOT ON example_repo 
WHERE SNAPSHOT = "backup1" AND TIMESTAMP = "2018-05-05-15-34-26";
4.3.1.5 查看在HDFS中生成的备份文件
 
4.3.2 从远端存储恢复备份到StarRocks库
4.3.2.1 RESTORE
恢复指定数据库、表或分区的数据，当前StarRocks仅支持恢复OLAP类型表。
数据恢复为异步操作，可以通过 SHOW RESTORE 语句查看恢复作业状态，或通过 CANCEL RESTORE 语句取消恢复作业。
提醒：单一数据库内，仅可同时执行一个备份或恢复作业，否则系统报错。
4.3.2.1.1 从远端仓库恢复备份数据至ssb库
从hdfs_repo仓库中恢复备份snapshot_dates中的表dates至数据库ssb，备份时间戳为2018-05-04-16-45-08，恢复为一个副本。
4.3.2.1.1.1 执行恢复语句
RESTORE SNAPSHOT ssb.dates_regain
FROM `hdfs_repo`
ON (`dates`)
PROPERTIES
(
"backup_timestamp"="yyyy-mm-dd-hh-mm-ss",
"replication_num" = "1"
);
 
执行恢复语句成功。
4.3.2.1.1.2 查看还原状态SHOW RESTORE
还原同样为异步操作，通过SHOW RESTORE FROM db_name语句查看还原状态(StarRocks中每个数据库也只会保存最近一次RESTORE任务)
SHOW RESTORE FROM ssb;
 
在数据还原过程中，会自动创建还原操作涉及到的表，创建完成后，这些表可见，但不能访问，需要等待还原任务完成后方可正常访问。
还原任务的状态信息我们通常只需要关注State、TaskErrMsg及Status：
1>    State：恢复作业当前所在阶段，根据任务进度可能会有八种状态：
PENDING：作业初始状态，等待调度。
SNAPSHOTING：正在进行本地新建表的快照操作。
DOWNLOAD：正在发送下载快照任务。
DOWNLOADING：快照正在下载。
COMMIT：准备生效已下载的快照。
COMMITTING：正在生效已下载的快照。
FINISHED：恢复完成，作业成功。
CANCELLED：恢复失败或被取消，通常为任务超时或任务失败。
2>    TaskErrMsg及Status：显示还原作业过程中可能出现的错误信息，如果任务失败，这里也会展示失败信息。同样的，只要State列不为CANCELLED，则说明作业依然在继续，作业中失败的task可能会重试成功，当然也有可能重试失败，最终导致任务CANCELLED。

与Backup操作时相同，当我们发现任务进度持续卡住，或者因为其他原因需要取消还原任务时，取消的语法为：CANCEL RESTORE FROM db_name;
再次强调，如果是覆盖表式的还原，当取消处于COMMIT或之后阶段的恢复作业时，可能导致数据损坏，进而导致被恢复的表无法访问。
4.3.2.1.1.3 确认表是否恢复
use ssb;
show tables;
 
select count(*) from dates_regain;
select count(*) from dates;
 
恢复成一张新表dates_regain，与执行备份时数据量相同，恢复成功。
select * from dates_regain limit 3;
 
4.4 集群监控部署及监控模板配置
StarRocks提供两种监控报警的方案。企业版用户可以使用内置的StarRocksManager，其自带的Agent从各个Host采集监控信息，上报至Center Service，然后做可视化展示。StarRocksManager提供邮件和Webhook的方式发送报警通知。
如果有二次开发需求，需要自行搭建部署监控服务，也可以使用开源Prometheus+Grafana方案，StarRocks提供了兼容Prometheus的信息采集接口，可以通过直接连接BE或FE的HTTP端口来获取集群的监控信息。
4.4.1 基于Prometheus+Grafana部署集群监控
我们可以使用Prometheus作为StarRocks监控数据存储方案，并使用Grafana作为可视化组件。
Prometheus是一个拥有多维度数据模型的、灵活的查询语句的时序数据库，它可以通过Pull或Push采集被监控系统的监控项，存入自身的时序数据库中，并且通过丰富的多维数据查询语言，满足用户的不同需求。
Grafana是一个开源的Metric分析及可视化系统，支持多种数据源，详情可参考官网文档。通过对应的查询语句，从数据源中获取展现数据，通过灵活可配置的Dashboard，快速的将这些数据以图表的形式展示给用户。
4.4.1.1 监控架构
Prometheus通过Pull方式访问FE或BE的Metric接口，然后将监控数据存入时序数据库。
用户可以通过Grafana配置Prometheus为数据源，自定义绘制Dashboard。
 
4.4.1.2 部署Prometheus
    下载并安装Prometheus
#从 Prometheus官网下载LTS版本的Prometheus
https://prometheus.io/download/
 
    上传到服务器目录并解压缩
在evoc-app1节点安装Prometheus
cd /usr/local/apps
tar -xf prometheus-2.45.0.linux-amd64.tar.gz
 
#为方便后续程序升级，将解压后的目录重命名为prometheus。
mv prometheus-2.45.0.linux-amd64 prometheus
    创建数据存放目录
cd /usr/local/apps/prometheus
mkdir data
    创建prometheus系统服务启动文件
prometheus官方只提供了二进制文件tar包，为了方便管理，我们可以创建prometheus系统服务启动文件。
cd /etc/systemd/system/
vim prometheus.service
[Unit]
Description=Prometheus service
After=network.target

[Service]
User=root
Type=simple
ExecReload=/bin/sh -c "/bin/kill -1 `/usr/bin/pgrep prometheus`"
ExecStop=/bin/sh -c "/bin/kill -9 `/usr/bin/pgrep prometheus`"
ExecStart=/usr/local/apps/prometheus/prometheus --config.file=/usr/local/apps/prometheus/prometheus.yml --storage.tsdb.path=/usr/local/apps/prometheus/data

[Install]
WantedBy=multi-user.target
重新加载某个服务的配置文件，如果新安装了一个服务，归属于systemctl管理，要是新服务的服务程序配置文件生效，需重新加载。
systemctl daemon-reload
    配置Prometheus
#在prometheus.yml中添加StarRocks监控相关的配置
cd /usr/local/apps/prometheus
vim prometheus.yml
 
    启动Prometheus
#不使用系统服务文件启动的方式
nohup ./prometheus \
--config.file="./prometheus.yml" \
--web.listen-address=":9090" \
--log.level="info" &
提示：该命令将后台运行Prometheus，并指定其Web端口为9090。启动后，即开始采集数据，并将数据存放在./data目录中。
#使用系统服务文件启动的方式(推荐)
systemctl enable prometheus.service    #开机启动
systemctl start prometheus.service    #启动服务
systemctl status prometheus.service    #查看状态
 
提示：查看启动状态，观察Active: active (running)即为启动成功。
prometheus默认使用的端口为9090，也可以使用netstat命令查看9090端口的状态：
netstat -nltp | grep 9090
 
    其他命令
停止服务：systemctl stop prometheus.service
重启服务：systemctl restart prometheus.service
热加载配置：systemctl reload prometheus.service
    设置开机启动
systemctl enable prometheus.service
4.4.1.3 访问prometheus
Prometheus可以通过web页面进行简单的访问，通过浏览器打开9090端口，即可访问Prometheus的页面。例如，我们使用谷歌浏览器访问172.21.228.92:9090。
 
点击导航栏中， Status-->Targets ，可以看到配置文件prometheus.yml中所有分组Job的监控主机节点。正常情况下，所有节点都应为UP，表示数据采集正常。
 
 
4.4.2    Grafana安装配置
2.4.2.1 Grafana下载上传安装
Grafana下载地址：
https://grafana.com/grafana/download/10.2.1?platform=linux
1>    使用yum命令安装
yum -y install grafana-enterprise-8.4.5-1.x86_64.rpm
2>    启动grafana
systemctl daemon-reload
systemctl start grafana-server.service
3>    查看状态
systemctl status grafana-server.service
Active: active (running) 表示服务已成功启动。
Grafana默认使用的端口为3000，使用netstat命令验证端口监听状态：
netstat -nltp | grep 3000
4>    设置开启自启
systemctl enable grafana-server.service
5>    扩展命令
关闭服务：systemctl stop grafana-server.service
重启服务：systemctl restart grafana-server.service

在之前已有安装Grafana，安装步骤省略，直接访问……
4.4.2.2 访问Grafana
使用浏览器访问172.21.228.92:3000 ，即可看到grafana页面，默认用户名密码都是admin/admin，初次登录会提示修改默认的登录密码，若暂时不希望修改密码，可以点击Skip跳过。跳过后即可进入到Grafana主界面：
 
4.4.2.3 数据源配置
配置路径为：Configuration-->Data sources-->Add data source-->Prometheus
选择Prometheus数据源进行配置，需要修改的配置参数有：
10>    Name：数据源的名称，可以自定义，例如starrocks_monitor。
11>    URL：Prometheus的web地址：http://172.21.228.92:9090
 
12>    完成后单击页面下方的Save&Test，如果显示Data source is working，即表示数据源可用。
 
4.4.2.4    配置DashBoard
1>    下载模板
StarRocks提供了Grafana DashBoard模版，下载地址为：
http://starrocks-thirdparty.oss-cn-zhangjiakou.aliyuncs.com/StarRocks-Overview-19.json
浏览器打开下载地址，右键，另存为，保存到桌面即可。
这里注意，我们需要将json文件下载到 “浏览器所在的机器上” ，因为json文件是需要通过浏览器上传的，所以这里不是下载到Linux服务器上，而是需要下载到咱们打开Web所用的机器上。
备注：2.4版本调整了metric信息，所以需要修改Json中的两处：
starrocks_be_memory_allocated_bytes为starrocks_be_process_mem_bytes。
2>    配置模板
点击左边的导航栏+号--> Import--> Upload Json File，将下载的json文件导入。
导入后，可以重命名为Dashboard，默认是StarRocks Overview。
同时，需要选择数据源，这里选择之前创建的starrocks_monitor。点击Import，即完成导入。
之后，可以看到StarRocks的Dashboard展示：
  
 
Import：上传文件StarRocks-Overview-19.json
 
4.4.2.5 后续访问
关闭浏览器后，如果需要再次进入监控Dashboard，还是在浏览器中访问 172.21.228.92:3000 ，输入用户名密码后，点击搜索按钮(Search dashboards)，选择StarRocks Overview即可。
  
4.4.2.5.1    监控区域分层
    Overview (8 panels)
    Cluster Overview (12 panels)
    Query Statistic (6 panels)
    Jobs (12 panels)
    Transaction (5 panels)
    FE JVM (8 panels)
    BE (16 panels)
    BE tasks (12 panels)
 
4.4.2.5.1.1 Overview
 
4.4.2.5.1.2 Cluster Overview
 
4.4.2.5.1.3 Query Statistic
 
4.4.2.5.1.4 Jobs
 
4.4.2.5.1.5 Transaction
 
4.4.2.5.1.6 FE JVM
 
4.4.2.5.1.7 BE
 
 
 
4.4.2.5.1.8 BE tasks
 
 
4.4.2.5.2 StarRocks Grafana监控指标介绍
详情访问URL：https://blog.csdn.net/Acer12138/article/details/125529210
4.5 负载均衡
在多个FE节点之上部署负载均衡层以实现StarRocks的高可用
4.5.1 通过代码均衡负载
您可以在应用层代码进行重试和负载均衡(Load Balance)。当特定连接宕机，代码应控制系统自动在其他连接上进行重试。使用该方式，您需要配置多个StarRocks前端节点地址。
4.5.2 通过JDBC Connector均衡负载
如果您使用MySQL JDBC Connector连接StarRocks，可以通过JDBC的自动重试机制进行重试和负载均衡。
4.5.3 通过ProxySQL均衡负载
ProxySQL是一个灵活强大的MySQL代理层，可以实现读写分离，支持Query路由、SQL Cache，动态加载配置、故障切换和SQL过滤等功能。
StarRocks的FE进程负责接收用户连接和查询请求，其本身是可以横向扩展且可以部署为高可用集群。您需要在多个FE节点上架设一层Proxy以实现自动的连接负载均衡。
4.5.3.1 核心特点与功能
ProxySQL是一款专为MySQL和MariaDB设计的高性能、高可用性的数据库中间件。
    读写分离
ProxySQL 自动处理数据库的读写分离，能够将读请求路由到只读副本上，而写请求则发送到主数据库，从而提高整体系统的读取性能和扩展性。
    智能路由
基于规则的查询路由功能，允许根据 SQL 查询的内容、用户、时间等多种条件动态地将请求路由到不同的后端数据库服务器。
    高并发支持
ProxySQL 采用先进的多核架构，设计上支持数十万级别的并发连接，并通过连接池和多路复用技术高效地管理这些连接，减少资源消耗。
    故障切换与高可用
实现自动故障检测和快速故障切换，当后端数据库出现故障时，ProxySQL 能够自动重新路由请求到其他可用的数据库节点，保证服务的连续性。
    动态配置与管理
支持动态加载配置，无需重启服务即可应用新的配置规则，简化了运维工作并减少了服务中断时间。
    SQL查询缓存
支持对特定 SQL 查询结果进行缓存，显著提升响应速度，减轻数据库负担。
    安全与审计
提供SQL注入防护、访问控制列表（ACL）和详细的SQL审计日志，增强数据库访问的安全性。
    性能优化
通过深度解析SQL语句，ProxySQL 能够帮助优化数据库集群的负载分布，提升整体性能。
    管理接口
包含一个强大的Admin管理接口，允许管理员通过SQL或HTTP API方式进行配置管理和监控，便于集成到现有的运维系统中。
4.5.3.2 应用场景
ProxySQL广泛应用于需要高性能、高可用性和可扩展性的MySQL/MariaDB环境，特别适合大型网站、在线服务、数据分析平台等需要处理大量数据库请求的场景。
4.5.3.3 总结
ProxySQL作为一款成熟的数据库中间件解决方案，它不仅解决了数据库层面的读写分离、负载均衡问题，还提供了丰富的管理功能和安全保障，是提升数据库服务性能和可靠性的有力工具。
4.5.3.4 ProxySQL
计划在佛山测试环境Starrocks集群evoc-sr2节点安装
4.5.3.4.1 单机部署172.21.235.213
    架构图
 
    安装相关依赖
yum install -y gnutls perl-DBD-MySQL perl-DBI perl-devel
#查看
ps -ef | grep perl-devel
rpm -qa|grep -i perl-devel
 
 
 
    下载上传并解压ProxySQL安装包
离线下载：
https://github.com/sysown/proxysql/releases/download/v2.0.14/proxysql-2.0.14-1-centos7.x86_64.rpm
解压缩：rpm2cpio proxysql-2.0.14-1-centos7.x86_64.rpm | cpio -ivdm
 
说明：您可以自行选择下载其他版本的 ProxySQL。
    修改配置文件
 
修改以下配置项为您有访问权限的目录（绝对路径）：
cd /usr/local/apps/etc
vim proxysql.cnf
datadir = "/usr/local/apps/proxysql"
errorlog = "/usr/local/apps/proxysql/proxysql.log"
 
    启动ProxySQL
cd /usr/local/apps
./usr/bin/proxysql -c ./etc/proxysql.cnf --no-monitor
 
#查看进程
ps -ef | grep proxysql
 
    登录StarRocks
mysql -u admin -padmin -h 127.0.0.1 -P6032
 
 
注意：ProxySQL默认包含两个端口，其中6032是ProxySQL的管理端口，6033是ProxySQL的流量转发端口，即对外提供服务的端口。
    配置全局日志
SET mysql-eventslog_filename='proxysql_queries.log';
SET mysql-eventslog_default_log=1;
SET mysql-eventslog_format=2;
LOAD MYSQL VARIABLES TO RUNTIME;
SAVE MYSQL VARIABLES TO DISK;
 
    插入主节点以及Observer节点并读取配置
insert into mysql_servers(hostgroup_id, hostname, port) values(1, '172.21.235.202', 9030);
insert into mysql_servers(hostgroup_id, hostname, port) values(1, '172.21.235.213', 9030);
insert into mysql_servers(hostgroup_id, hostname, port) values(1, '172.21.235.227', 9030);
load mysql servers to runtime;
save mysql servers to disk;
 
 
    配置用户名和密码并读取配置
mysql -h172.21.235.202 -uroot -P 9030 -p
select password('evoc@1993');
注意：这里password输入值为密文，需另开窗口连接FE获取密码。例如root用户密码为root123，则password输入为*696226E29C243936BAED0EA7286A5E949DDC22C1。您可以通过password()函数获取具体输入的加密值。
 
在172.21.235.213上执行：
insert into mysql_users(username, password, active, default_hostgroup, backend, frontend) values('root', '*696226E29C243936BAED0EA7286A5E949DDC22C1', 1, 1, 1, 1);
load mysql users to runtime; 
save mysql users to disk;
 
    写入代理规则并读取配置
insert into mysql_query_rules(rule_id, active, match_digest, destination_hostgroup, mirror_hostgroup, apply) values(1, 1, '.', 1, 2, 1);
load mysql query rules to runtime; 
save mysql query rules to disk;
 
    验证
完成以上步骤后，就可以通过ProxySQL经由6033端口对数据库进行操作。
mysql -uroot -pevoc@1993 -P6033 -h172.21.235.213 -e"select * from test.student"
或
mysql -uroot -p -P6033 -h172.21.235.213 -e"select * from test.student"
 
 
说明：如果结果正常返回，则表示您已成功通过ProxySQL连接StarRocks。连接查询验证成功。
#测试故障转移
先停掉Leader FE实例：172.21.235.213
./stargo cluster stop sr-cluster --node 172.21.235.213:9010
说明：该节点不仅是FE主节点，也是安装Proxysql服务的节点。
 
在已停止FE实例的172.21.235.213服务器上用ProxySQL方式连接查询Starrocks表：
mysql -uroot -pevoc@1993 -P6033 -h172.21.235.213 -e"select * from test.student"
 
说明：连接查询表数据成功。这表示主FE节点实例停止服务，通过ProxySQL方式连接Starrocks集群，实现自动转移故障连接到其它正常的FE实例服务上，避免连接到发生故障的主FE节点，造成无法访问SR集群的情况。
不用业务层去轮询FE服务，在数据库层面实现故障自动转移，FE服务高可用。
    通过ProxySQL登入Starrocks
mysql -uroot -pevoc@1993 -P6033 -h172.21.235.213
 
4.5.3.4.2 部署第二台172.21.235.227
#上传rpm安装包到服务器
cd /usr/local/apps
#直接安装rpm方式
rpm -ivh proxysql-2.0.14-1-centos7.x86_64.rpm
 
说明：安装完成，默认安装到根目录下/etc中去了。
 
#修改配置文件
修改以下配置项为您有访问权限的目录（绝对路径）：
vim /etc/proxysql.cnf
datadir = "/var/lib/proxysql"
errorlog = "/var/lib/proxysql/proxysql.log"
 
说明：默认有/var/lib/proxysql目录，不用修改。
#启动ProxySQL
依赖proxysql.service文件(安装自动生成)，文件中启动参数需指定脚本和配置文件，这里默认无需任何改动。
cd /etc/systemd/system
cat proxysql.service
 
查看/usr/bin目录下启动脚本在不在：proxysql
 
#先查看proxysql状态
systemctl status proxysql
 
#启动proxysql
systemctl start proxysql
再查看状态：systemctl status proxysql
 
说明：启动成功，状态正常。
#登录StarRocks
mysql -u admin -padmin -h 127.0.0.1 -P6032
show databases;
 
注意：ProxySQL默认包含两个端口，其中6032是ProxySQL的管理端口，6033是ProxySQL 的流量转发端口，即对外提供服务的端口。
#配置全局日志
SET mysql-eventslog_filename='proxysql_queries.log';
SET mysql-eventslog_default_log=1;
SET mysql-eventslog_format=2;
LOAD MYSQL VARIABLES TO RUNTIME;
SAVE MYSQL VARIABLES TO DISK;
 
#插入主节点以及Observer节点并读取配置
insert into mysql_servers(hostgroup_id, hostname, port) values(1, '172.21.235.202', 9030);
insert into mysql_servers(hostgroup_id, hostname, port) values(1, '172.21.235.213', 9030);
insert into mysql_servers(hostgroup_id, hostname, port) values(1, '172.21.235.227', 9030);
load mysql servers to runtime;
save mysql servers to disk;
 
 
#配置用户名和密码并读取配置
insert into mysql_users(username, password, active, default_hostgroup, backend, frontend) values('root', '*696226E29C243936BAED0EA7286A5E949DDC22C1', 1, 1, 1, 1);
load mysql users to runtime; 
save mysql users to disk;
 
#写入代理规则并读取配置
insert into mysql_query_rules(rule_id, active, match_digest, destination_hostgroup, mirror_hostgroup, apply) values(1, 1, '.', 1, 2, 1);
load mysql query rules to runtime; 
save mysql query rules to disk;
 
#通过ProxySQL经由6033端口对数据库进行操作
mysql -uroot -pevoc@1993 -P6033 -h172.21.235.213 -e"select * from test.student"
 
 
4.5.3.4.3 遇到问题
mysql -uroot -pevoc@1993 -P6033 -h172.21.235.213 -e"select * from test.student"
问题一：连接访问不稳定
配置好负载均衡后，通过ProxySQL访问6033端口，有时能连接查询到，有时连接查询不到报错。
 
说明：暂时没找到问题原因。
问题二：使用systemctl方式无法启停ProxySQL
cd /usr/lib/systemd/system
vim proxysql.service
[Unit]
Description=High Performance Advanced Proxy for MySQL
After=network.target

[Service]
Type=forking
RuntimeDirectory=proxysql
#PermissionsStartOnly=true
#ExecStartPre=/usr/bin/mkdir -p /var/run/proxysql /var/run/proxysql
#ExecStartPre=/usr/bin/chown -R proxysql: /var/run/proxysql/
#ExecStart=/usr/bin/proxysql --idle-threads -c /etc/proxysql.cnf $PROXYSQL_OPTS
#PIDFile=/var/lib/proxysql/proxysql.pid

ExecStart=/usr/local/apps/usr/bin/proxysql --idle-threads -c /usr/local/apps/etc/proxysql.cnf
PIDFile=/usr/local/apps/proxysql/proxysql.pid

#StandardError=null  # all output is in stderr
SyslogIdentifier=proxysql
Restart=no
User=proxysql
Group=proxysql
PermissionsStartOnly=true
UMask=0007
LimitNOFILE=102400
LimitCORE=1073741824
ProtectHome=yes
NoNewPrivileges=true
CapabilityBoundingSet=CAP_SETGID CAP_SETUID CAP_SYS_RESOURCE
RestrictAddressFamilies=AF_INET AF_INET6 AF_UNIX AF_ALG
ProtectSystem=full
PrivateDevices=yes

[Install]
WantedBy=multi-user.target
查看proxysql状态：systemctl status proxysql
 
启动proxysql：systemctl start proxysql
 
说明：启动失败，查看详细信息journalctl –xe。
 
报错详情：报错找不到文件Failed at step USER spawning /usr/local/apps/usr/bin/proxysql: No such process，但该路径下明明就有proxysql。
 
说明：暂没找到问题在哪，另外尝试其他方法。
问题三：在ProxySQL做的负载均衡配置信息没了
连接ProxySQL：mysql -u admin -padmin -h 127.0.0.1 -P6032
 
说明：05.15配置好之后连接负载均衡访问正常，16号上午在尝试启停proxysql的其他方法，不知怎么的负载均衡连接不上，在登录查询，发现负载均衡配置表信息没了，这种情况不好复现。

4.5.4 通过HAProxy负载均衡
HAProxy (High Availability Proxy)是一个免费、开源的负载均衡软件，主要用于提供高可用性和负载均衡解决方案。
4.5.4.1 主要特点
    高性能
HAProxy被设计为轻量级且高效的解决方案，能够处理大量的并发连接，尤其擅长处理 HTTP、HTTPS和TCP流量。
    七层和四层负载均衡
支持工作在OSI模型的第4层(TCP/UDP 层)和第7层(HTTP层)，可以根据不同的应用需求选择合适的负载均衡策略。
    多种负载均衡算法:
提供多种负载均衡算法，如轮询(round-robin)、最少连接(least connections)、基于哈希的会话持久化(source hashing)等。
    健康检查
自动进行后端服务器的健康检查，确保只将请求转发给正常运行的服务实例。
    安全性
支持SSL/TLS终止，可以加密客户端与代理之间的通信，同时可以解密流量以便进行基于内容的路由。
    易配置
使用简单的文本配置文件，易于理解和管理，支持动态配置更新。
    日志记录
可以将日志发送到syslog或其他日志收集系统，方便监控和分析。
    扩展性
通过插件和模块化设计，可以扩展HAProxy的功能以满足特定需求。
4.5.4.2 应用场景
HAProxy广泛应用于各种场景，包括但不限于：
    Web服务器负载均衡: 分发Web请求到多个后端服务器，提高响应速度和可靠性。
    API网关: 在微服务架构中，作为统一的入口点，实现对后端服务的负载均衡和访问控制。
    数据库负载均衡: 虽然不是专为数据库设计，但可以用于TCP层的数据库连接负载均衡。
    CDN边缘节点: 在CDN网络中作为边缘服务器，负责缓存和分发内容。
    企业内部服务: 在企业内部网络中，为内部服务提供高可用和负载均衡。
4.5.4.3 总结
HAProxy是一个强大且灵活的工具，它为需要高可用性和负载均衡的企业提供了可靠的解决方案，广泛应用于需要处理大量网络流量的场景。由于其开源性质，它拥有活跃的社区支持，不断更新和改进，以适应不断变化的网络环境。
4.5.5 ProxSQL和HAProxy的区别
ProxySQL和HAProxy都是常用的数据库和网络流量管理工具，但它们在用途和功能上有所区别。
4.5.5.1 ProxySQL
    主要用途
ProxySQL 是一款高性能的 MySQL 和 MariaDB 数据库代理，专注于数据库层的负载均衡和管理。
    层次
它工作在应用层（通常视为七层），能够理解 SQL 查询，提供智能路由、读写分离、缓存、以及复杂的数据库管理和监控功能。
    优点
1.    能够根据查询类型智能路由，例如将读操作导向只读副本。
2.    支持动态会话亲和性，确保同一客户端的连接保持在同一服务器上。
3.    提供SQL审计和安全特性。
4.    可以直接与数据库管理系统交互，进行故障切换和负载均衡。
    缺点
1.    主要针对 MySQL 和 MariaDB，对其他数据库系统支持有限。
2.    相较于纯粹的负载均衡器，配置和管理可能更为复杂。
4.5.5.2 HAProxy
    主要用途
HAProxy是一个通用的负载均衡器，常用于 HTTP、HTTPS以及其他TCP应用。
    层次
它既可以工作在四层（TCP/UDP 层），也可以工作在七层（HTTP/HTTPS 层），提供基于内容的路由。
    优点
1.    高性能，处理大量并发连接。
2.    支持多种健康检查机制，确保只将流量转发到健康的服务器。
3.    易于配置和扩展，适用于多种服务场景。
4.    支持会话持久化和虚拟主机。
    缺点
1.    不是专门针对数据库的，对 SQL 查询没有理解能力。
2.    对于数据库特定的路由策略和优化不如 ProxySQL 强大。

    总结
选择ProxySQL还是HAProxy取决于具体的应用场景。如果需要对MySQL或MariaDB数据库进行高级管理和优化，ProxySQL更合适。
如果需要一个通用的负载均衡解决方案，尤其是对于HTTP流量，HAProxy是一个常见且强大的选择。
4.6    管理Starrocks中的审计日志
    在测试环境Starrocks集群安装(不归属项目)
IP    主机名    角色    CPU(GB)    内存    系统盘(GB)    数据盘(GB)
172.21.235.202    evoc-sr1    FE    32->2    16->4    100    200
172.21.235.213    evoc-sr2    FE    32->2    16->4    100    200
172.21.235.227    evoc-sr3    FE    32->2    16->4    100    200
172.21.235.212    evoc-sr4    BE    32->2    16->4    100    1000
172.21.235.217    evoc-sr5    BE    32->2    16->4    100    1000
172.21.235.224    evoc-sr6    BE    32->2    16->8    100    1000
说明：只需在FE节点安装插件AuditLoader.zip
4.6.1 通过 AuditLoader 管理 StarRocks 中的审计日志
本文档介绍如何通过插件 AuditLoader 在 StarRocks 内部管理审计日志。
在StarRocks中，所有的审计信息仅存储在日志文件fe/log/fe.audit.log中，无法直接通过StarRocks进行访问。AuditLoader插件可实现审计信息的入库，让您在StarRocks内方便的通过SQL进行集群审计信息的查看和管理。安装AuditLoader插件后，StarRocks在执行SQL 后会自动调用AuditLoader插件收集SQL的审计信息，然后将审计信息在内存中攒批，最后基于Stream Load的方式导入至StarRocks表中。
4.6.1.1 创建审计日志库表
在StarRocks集群中为审计日志创建数据库和表
CREATE DATABASE starrocks_audit_db__;

CREATE TABLE starrocks_audit_db__.starrocks_audit_tbl__ (
  `queryId`           VARCHAR(64)                COMMENT "查询的唯一ID",
  `timestamp`         DATETIME         NOT NULL  COMMENT "查询开始时间",
  `queryType`         VARCHAR(12)                COMMENT "查询类型（query, slow_query, connection）",
  `clientIp`          VARCHAR(32)                COMMENT "客户端IP",
  `user`              VARCHAR(64)                COMMENT "查询用户名",
  `authorizedUser`    VARCHAR(64)                COMMENT "用户唯一标识，既user_identity",
  `resourceGroup`     VARCHAR(64)                COMMENT "资源组名",
  `catalog`           VARCHAR(32)                COMMENT "Catalog名",
  `db`                VARCHAR(96)                COMMENT "查询所在数据库",
  `state`             VARCHAR(8)                 COMMENT "查询状态（EOF，ERR，OK）",
  `errorCode`         VARCHAR(512)               COMMENT "错误码",
  `queryTime`         BIGINT                     COMMENT "查询执行时间（毫秒）",
  `scanBytes`         BIGINT                     COMMENT "查询扫描的字节数",
  `scanRows`          BIGINT                     COMMENT "查询扫描的记录行数",
  `returnRows`        BIGINT                     COMMENT "查询返回的结果行数",
  `cpuCostNs`         BIGINT                     COMMENT "查询CPU耗时（纳秒）",
  `memCostBytes`      BIGINT                     COMMENT "查询消耗内存（字节）",
  `stmtId`            INT                        COMMENT "SQL语句增量ID",
  `isQuery`           TINYINT                    COMMENT "SQL是否为查询（1或0）",
  `feIp`              VARCHAR(128)               COMMENT "执行该语句的FE IP",
  `stmt`              VARCHAR(1048576)           COMMENT "原始SQL语句",
  `digest`            VARCHAR(32)                COMMENT "慢SQL指纹",
  `planCpuCosts`      DOUBLE                     COMMENT "查询规划阶段CPU占用（纳秒）",
  `planMemCosts`      DOUBLE                     COMMENT "查询规划阶段内存占用（字节）"
) ENGINE = OLAP
DUPLICATE KEY (`queryId`, `timestamp`, `queryType`)
COMMENT "审计日志表"
PARTITION BY RANGE (`timestamp`) ()
DISTRIBUTED BY HASH (`queryId`) BUCKETS 3 
PROPERTIES (
  "dynamic_partition.time_unit" = "DAY",
  "dynamic_partition.start" = "-30",  --表示只保留最近30天的审计信息，可视需求调整。
  "dynamic_partition.end" = "3",
  "dynamic_partition.prefix" = "p",
  "dynamic_partition.buckets" = "3",
  "dynamic_partition.enable" = "true",
  "replication_num" = "3"  --若集群中BE个数不大于3，可调整副本数为1，生产集群不推荐调整。
);
 
 
说明：starrocks_audit_tbl__ 表是动态分区表。 默认情况下，第一个动态分区将在建表后10分钟创建。分区创建后审计日志方可导入至表中。 
#检查表中的分区是否创建完成
SHOW PARTITIONS FROM starrocks_audit_db__.starrocks_audit_tbl__;
 
 
说明：待分区创建完成后，可以继续下一步。
4.6.1.2 下载并配置AuditLoader
    下载AuditLoader安装包。该插件兼容目前在维护的所有StarRocks版本。
    解压安装包
unzip auditloader.zip
 
解压生成以下文件：
1.    auditloader.jar：审计插件代码编译后得到的程序jar包。
2.    plugin.properties：插件属性文件，用于提供审计插件在StarRocks集群内的描述信息，无需修改。
3.    plugin.conf：插件配置文件，用于提供插件底层进行Stream Load写入时的配置参数，需根据集群信息修改。通常只建议修改其中的user和password信息。
    修改plugin.conf文件以配置AuditLoader。
必须配置以下项目以确保AuditLoader可以正常工作：
1.    frontend_host_port：FE节点IP地址和HTTP端口，格式为<fe_ip>:<fe_http_port>。默认值为127.0.0.1:8030。
2.    database：审计日志库名。
3.    table：审计日志表名。
4.    user：集群用户名。该用户必须具有对应表的INSERT权限。
5.    password：集群用户密码。
vim plugin.conf
 
说明：仅修改集群账号和密码即可，frontend_host_port默认不动。
    重新打包以上文件
yum install zip
zip -q -m -r auditloader.zip auditloader.jar plugin.conf plugin.properties
 
    将压缩包分发至所有FE节点运行的机器
请确保所有压缩包都存储在相同的路径下，否则插件将安装失败。分发完成后，请复制压缩包的绝对路径。
cd /usr/local/apps
 
4.6.1.3 安装AuditLoader
https://docs.starrocks.io/zh/docs/administration/management/audit_loader/#%E9%AA%8C%E8%AF%81%E5%AE%89%E8%A3%85%E5%B9%B6%E6%9F%A5%E8%AF%A2%E5%AE%A1%E8%AE%A1%E6%97%A5%E5%BF%97
#通过以下语句安装AuditLoader插件
INSTALL PLUGIN FROM "/usr/local/apps/auditloader.zip";
 
官方文档：
https://docs.starrocks.io/zh/docs/sql-reference/sql-statements/Administration/INSTALL_PLUGIN/
4.6.1.4 验证安装并查询审计日志
#通过SHOW PLUGINS语句检查插件是否安装成功
SHOW PLUGINS\G
 
说明：插件AuditLoader的Status为INSTALLED，即代表安装成功。
第一行显示描述：内置审核日志记录器
第二行显示描述：可用于2.3+版本。将审计日志加载到starrocks，用户可以查看查询的统计信息。
#随机执行SQL语句以生成审计日志
执行SQL语句并等待60秒（或在配置AuditLoader时在max_batch_interval_sec项中指定的时间）以允许AuditLoader将审计日志攒批导入至StarRocks中。
max_batch_interval_sec参数在plugin.conf文件中设置
#查询审计日志表
SELECT * FROM starrocks_audit_db__.starrocks_audit_tbl__;
 
说明：查询审计表，审计日志中的历史记录已导入到starrocks_audit_tbl__表中。
#执行SQL查询并查看审计数据是否导入表中
select * from ssb.customer limit 10;
SELECT `timestamp`,returnRows,stmt FROM starrocks_audit_db__.starrocks_audit_tbl__;
SELECT count(*) FROM starrocks_audit_db__.starrocks_audit_tbl__;
 
说明：执行任意SQL查询，等待60s后审计表已能看到执行的sql操作记录，当前共有293条记录。
4.6.1.5 故障排除
如果在动态分区创建成功且插件安装成功后仍然长时间没有审计日志导入至表中，您需要检查plugin.conf文件是否配置正确。
如需修改配置文件，您需要首先卸载插件：UNINSTALL PLUGIN AuditLoader;
说明：所有配置设置正确后，可以按照上述步骤重新安装。
    如何停止导入审计数据
官网没看到如何停止导入审计日志到审计表的操作
社区pmc说是直接删除审计表
mysql -h172.21.235.202 -uroot -P 9030 –p
use starrocks_audit_db__;
drop table starrocks_audit_tbl__;
 
4.6.1.5 查看占用集群资源情况



说明：没安装审计插件前，BE CPU使用：138MB  安装运行1小时后使用：181MB。