RustFS 1.0.0-rc.5 发布：GA 前的最后一次大版本打磨

一句话定位：RustFS 是面向 AI 时代、从零原生打造的高性能分布式对象存储，100% 兼容 S3 API，Apache 2.0 协议，底层用 Rust 构建，可作为 MinIO 的 drop-in 替代方案。

RustFS 在 2026-09-02 推了 1.0.0-rc.5。如果只看版本号，它只是 GA 之前的又一个候选版本；但点开 release notes 会发现，这一版一次合并了约 160 个 PR（编号从 #6752 到 #7025），把复制、加密、查询、部署四条线都往前推了一截。对一个已经临近正式版的存储引擎来说，这种密度不是修修 bug 凑数，而是在把"生产级"那几块短板补齐。

我自己在 staging 环境跟过 rc.1 到 rc.4 的升级，最直观的感受是：每过一个 RC，复制和加密这两个最怕出事的子系统就稳一点。rc.5 正好把这两块又钉死了一批边界。

1. 为什么一个 RC 值得单独写

对象存储的版本号很容易让人疲劳------"又是个 RC 而已"。但 rc.5 有三个理由让它值得上手试：

它是 GA（官方路线图指向 2026 年 9 月中旬）之前最新的候选版本，很多 rc 阶段的能力会在 GA 里定型，现在摸索成本最低。
这一版的变更集中在"运维最怕踩坑"的地方：跨集群复制、加密密钥持久化、服务端查询。
GitHub 星标已经到 31.6K 量级（截至 2026-09-04，releasealert 统计），社区迭代节奏没降。

换句话说，rc.5 是"上车前的最后一班平稳列车"。下面的拆解都围绕"上生产前要不会踩的坑"来写。

2. rc.5 改了什么：四块最值得关注的变更

2.1 站点复制和对象锁终于对齐了

多集群容灾里最拧巴的一件事是：你开了对象锁定（WORM / 合规模式）保证数据不可改，结果复制把一份"已删除版本"同步过去，把对端的锁状态悄悄绕开了。rc.5 把这条链路补上了：

fix(replication): 让复制的版本清除通过对等 WORM 门（#6960）------对端有合规锁的对象，复制不会强行清掉。
fix(replication): 暴露对象锁拒绝的清除并退避修复重试（#6900）------锁拒绝不再被静默吞掉，而是进重试队列，可观测。

这对金融、医疗这类有保留期法规的场景是直接利好：主站点锁住的对象，在复制目标上也不会被意外清掉。

2.2 KMS 重启后配置不再丢

加密集群最怕滚动重启后密钥状态对不上。fix(kms): 重启后恢复持久化配置（#6821）让 RustFS 重启后能把自己的 KMS 配置重新读回来，不用每次重启都手工确认。配合 rc.1 已经推到生产就绪的 KMS 后端（local / Vault KV2 / Vault Transit），加密集群的运维连续性好了一大截。

2.3 S3 Select 与 S3 Tables 继续长肉

rc.5 在查询侧也加了料：S3 Select 现在支持压缩的 CSV / JSON 输入（#6915）、流式 JSON 文档输入（#6980），S3 Tables / Table Catalog 支持对象支持的表重命名（#6899）和从 LoadTable 下发凭证（#6878）。对湖仓场景，这意味着"在存储层就过滤、少搬数据"这条路更宽了。

2.4 小对象读路径又优化了一轮

perf(storage): 优化小对象 GET/PUT 路径（#6770）、perf(ecstore): 优化有界小对象 GET 路径（#6808），再加上 quorum 感知的 GET 提前停止（#6885）。这几条都是针对高频小文件------AI 训练元数据、日志、事件流------的延迟优化。具体收益要看你的硬件和并发，但方向是小对象读写更省。

3. 升级到 rc.5：可照做的步骤

无论你是 docker 还是二进制部署，先把版本钉死再动，别用 latest：

bash 复制代码

docker pull rustfs/rustfs:1.0.0-rc.5

export RUSTFS_ACCESS_KEY="your-access-key"
export RUSTFS_SECRET_KEY="your-strong-secret"
export RUSTFS_RPC_SECRET="another-strong-secret"

docker run -d --name rustfs -p 9000:9000 -p 9001:9001 \
  -e RUSTFS_ACCESS_KEY -e RUSTFS_SECRET_KEY -e RUSTFS_RPC_SECRET \
  -v $(pwd)/data:/data -v $(pwd)/logs:/logs \
  rustfs/rustfs:1.0.0-rc.5 server /data --console-address ":9001"

rc alias set local http://127.0.0.1:9000 "$RUSTFS_ACCESS_KEY" "$RUSTFS_SECRET_KEY"
rc admin info local
rc --version

升级完别急着切流量，先在 staging 跑一轮冒烟：建桶、PUT/GET、预签名、分页列举、版本控制开关。确认版本号对得上再往生产推。

4. 几个要记牢的边界

rc.5 没有官方标记的 BREAKING CHANGE，但有几处行为变了，旧部署可能要改：

Rust 最低支持版本收紧（#6990）。从源码编译的话，编译器要升到新的 MSRV；用官方二进制 / 镜像不受影响。
Azure 分层配置变严 （#6817）。storageClass / spAuth 写法不合法时，rc.5 会拒绝而不是像以前那样静默忽略------含无效 Azure tier 配置的旧部署启动可能报错，先核对。
rc 仍是预发布。GA 之前建议先在 staging 验证、固定版本标签，不要裸奔上生产核心数据。
复制是异步的。对象锁对齐解决的是"锁不被复制绕过"，不解决跨站点秒级一致------合规场景仍要按异步复制设计 RPO。

5. 一张图看懂 rc.5 的重点

上面那张表已经把四块变更和运维意义列清楚了。补一句判断：如果你正在做 MinIO 迁移或信创替代的评估，rc.5 这一版让"复制 + 加密 + 查询"三件套更接近可放心上生产的样子，适合作为选型验证的基线版本。

6. 总结与下一步

rc.5 不是功能大爆炸，而是把临近 GA 的几条生产关键链路------复制与合规锁对齐、KMS 重启持久化、服务端查询、小对象读路径------又夯实了一轮。对一个存储系统，这种"看起来不起眼但半夜不叫醒你"的改动，比新特性更值钱。

下一步可以这么动：

把 staging 集群钉到 1.0.0-rc.5，跑一遍建桶 / 上传 / 预签名 / 列举 / 版本控制的冒烟。
已经开了对象锁或 KMS 的，重点验证复制链路在重启后锁状态是否一致。
等 9 月中旬 GA 后，再按固定 GA 版本标签做生产滚动升级。

RustFS 的源码、release notes 和 issue 都在 github.com/rustfs/rustfs，升级前对照对应版本的 release notes 核一遍就行。

深入学习 RustFS ：RustFS

技术文档： RustFS 技术文档- 提供架构、安装指南和 API 参考。

GitHub 仓库： GitHub 仓库 - 获取源代码、提交问题或贡献代码。