StarRocks 备份与恢复实战基于 MinIO 的 S3 存储方案为什么需要备份StarRocks 作为一款 OLAP 分析型数据库承载着大量业务报表和数据分析结果。虽然数据通常有上游数据源可以重跑但以下场景备份依然必不可少误操作恢复DDL 误删表、数据误更新等版本升级回滚大版本升级前做快照出问题可快速回溯跨集群迁移从测试环境到生产环境的数据同步灾备合规满足数据安全审计要求StarRocks 从 2.3 版本开始支持基于 Broker 的备份恢复能力到 2.5 版本功能趋于完善。备份恢复原理StarRocks 的备份恢复依赖Broker 组件作为中间桥梁将数据以快照Snapshot形式导出到外部存储。架构如下FE (元数据调度) → Broker (数据传输) → S3/HDFS 存储 ↑ BE (数据文件) ───┘支持的存储后端S3 兼容的对象存储MinIO、AWS S3、阿里云 OSS 等HDFS版本差异版本支持范围限制2.3表级备份仅支持 Duplicate/Aggregate/Unique 模型不支持主键表、不支持物化视图、不支持整库备份2.5支持主键表、支持整库备份恢复—3.3功能趋于稳定主键表部分场景仍有注意事项注意备份恢复目前不支持主键模型Primary Key的表这是需要关注的限制。环境准备本文以 MinIO 作为 S3 兼容存储后端。MinIO 是一个开源的对象存储服务部署简单兼容 S3 协议。启动 MinIODocker 方式dockerrun-d\--nameminio\-p9000:9000-p9001:9001\-eMINIO_ROOT_USERadmin\-eMINIO_ROOT_PASSWORDadmin123456\-v/data/minio:/data\minio/minio server /data --console-address:9001访问http://your_ip:9001进入 MinIO 控制台创建一个 Bucket 命名为srbackup。确保 Broker 服务正常运行# 检查 Broker 状态mysql-h127.0.0.1-P9030-uroot-eSHOW PROC /brokers;如果 Broker 未启动/data/StarRocks-3.1.7/apache_hdfs_broker/bin/start_broker.sh--daemon创建备份仓库备份仓库Repository是 StarRocks 中备份数据的存储目标创建后可通过SHOW REPOSITORIES查看。CREATEREPOSITORYsrbackupWITHBROKERbroker1ONLOCATIONs3a://srbackupPROPERTIES(fs.s3a.access.keyyour_access_key,fs.s3a.secret.keyyour_secret_key,fs.s3a.endpointhttp://192.168.1.100:9000,fs.s3a.connection.ssl.enabledfalse);参数说明参数说明REPOSITORY仓库名称后续备份恢复时引用BROKERBroker 名称需与SHOW PROC /brokers中一致LOCATIONS3 Bucket 路径格式s3a://bucket_namefs.s3a.access.keyS3 Access Keyfs.s3a.secret.keyS3 Secret Keyfs.s3a.endpointS3 服务端点地址fs.s3a.connection.ssl.enabled是否启用 SSLMinIO 本地部署通常设为 false查看已创建的仓库SHOWREPOSITORIES;执行备份表级备份BACKUPSNAPSHOTa003.backup_1TOsrbackupON(tab1,tab2,tab3)PROPERTIES(typefull);说明SNAPSHOT后跟快照名称建议包含库名和版本号如db_name.backup_20260701ON (...)指定要备份的表名列表type full表示全量备份目前仅支持全量模式查看备份进度-- 查看备份任务状态SHOWBACKUPFROMa003;-- 查看仓库中的快照列表SHOWSNAPSHOTONsrbackup;SHOW BACKUP输出关键字段StatusCANCELLED/DOING/FINISHEDTaskMsg错误时会显示详细错误信息CreateTime/FinishTime可据此计算备份耗时执行恢复在目标集群创建相同的仓库恢复时需要指定backup_timestamp可从SHOW SNAPSHOT ON srbackup的Snapshot名称中获取。-- 1. 先在目标集群创建指向同一 S3 的仓库CREATEREPOSITORYsrbackupWITHBROKERbroker1ONLOCATIONs3a://srbackupPROPERTIES(fs.s3a.access.keyyour_access_key,fs.s3a.secret.keyyour_secret_key,fs.s3a.endpointhttp://192.168.1.100:9000,fs.s3a.connection.ssl.enabledfalse);-- 2. 查看可用快照获取 backup_timestampSHOWSNAPSHOTONsrbackup;-- 3. 执行恢复RESTORESNAPSHOTa003.backup_1FROMsrbackupON(tab1,tab2,tab3)PROPERTIES(backup_timestamp2022-10-28-11-25-16-351);-- 4. 查看恢复进度SHOWRESTORE;backup_timestamp获取方式执行SHOW SNAPSHOT ON srbackup后输出的快照名称格式为backup_name.backup_timestamp取.后面的时间戳部分即可。删除备份快照-- 删除指定快照DROPSNAPSHOTa003.backup_1ONsrbackup;常见问题与注意事项1. 主键表不支持备份恢复这是最需要注意的限制。2.3 版本明确不支持2.5 版本有所改善但部分场景仍有问题。建议在生产使用前在测试环境充分验证。2. 备份期间的影响备份操作会占用 FE 和 BE 的计算资源及网络带宽建议在业务低峰期执行尤其是大表全量备份。3. 恢复前需确保表不存在RESTORE 操作要求目标库中不存在同名表否则恢复会失败。如需覆盖先手动 DROP 目标表。4. 跨版本兼容性备份文件与 StarRocks 版本相关跨主版本恢复如从 2.3 恢复到 3.1可能存在兼容性问题。建议在同版本或相邻版本间做备份恢复。5. 备份存储容量规划全量备份会复制所有数据文件到 S3需根据数据量预估存储空间。建议在 MinIO Bucket 上配置生命周期策略自动清理过期快照。自动化备份脚本以下是一个简单的 Shell 备份脚本配合 crontab 实现定期备份#!/bin/bash# starrocks_backup.shFE_HOST127.0.0.1FE_PORT9030USERrootPASSWORDyour_passwordDB_NAMEa003BACKUP_NAME${DB_NAME}.backup_$(date%Y%m%d)mysql-h${FE_HOST}-P${FE_PORT}-u${USER}-p${PASSWORD}-e BACKUP SNAPSHOT${BACKUP_NAME}TO srbackup ON (tab1, tab2, tab3) PROPERTIES (type full); echoBackup${BACKUP_NAME}submitted at$(date)# crontab每周日凌晨 3 点执行03* *0/path/to/starrocks_backup.sh/var/log/sr_backup.log21总结StarRocks 的备份恢复功能整体比较简单核心流程就是建仓库 → 打快照 → 查看状态。关键注意点提前规划 S3 存储MinIO 轻量够用注意主键表的兼容性限制跨版本恢复前做好测试配合 crontab 实现自动化降低人工操作风险备份是运维的最后一道防线有了它你才敢放心折腾。
