MinIO集群基于纠删码而非传统分布式分片，需4–16个偶数节点统一启动、共享配置与凭证；不支持单节点多实例拼凑、运行中扩盘或单节点升级，扩容须停机增加完整节点组。
MinIO 本身不支持传统意义上的“集群自动分片+元数据同步”式分布式存储，所谓“MinIO 集群”实际是基于 erasure coding 的纠删码部署模式，节点数必须为 4–16 的偶数，且所有节点需共享同一份配置、同一套启动命令——不是 Kubernetes StatefulSet 那种弹性扩缩容集群，而是静态拓扑的高性能对象存储阵列。
为什么不能直接用单节点 minio server 启动多实例凑成集群
直接运行多个独立 minio server /data 实例，彼此无协调机制：上传对象会重复写入、删除只作用于单节点、List 操作无法跨节点聚合。MinIO 的集群能力依赖 minio server 启动时传入的多个磁盘路径（或节点地址），由内置的 healing 和 erasure set 逻辑统一管理。
- 必须用
minio server一次性启动全部节点，格式为：minio server http://node{1...4}/mnt/disk{1...2} - 每个
http://nodeX/...必须能被所有其他节点反向解析和访问（DNS 或 hosts 要配通，端口默认 9000） - 所有节点的
MINIO_ROOT_USER和MINIO_ROOT_PASSWORD环境变量必须完全一致，否则初始化失败并报错Unable to initialize config store: invalid credentials
四节点八盘（4×2）纠删码集群的实际部署命令
以 4 台服务器（node1–node4）、每台挂载 2 块裸盘（/mnt/disk1, /mnt/disk2）为例，这是 MinIO 官方推荐的最小生产级拓扑（提供 4+4 纠删码，容忍任意 4 节点宕机或 4 块盘故障）。
在每台机器上执行相同命令（仅修改本机 hostname）：
export MINIO_ROOT_USER=admin
export MINIO_ROOT_PASSWORD=your-secure-password-123
minio server \
http://node1/mnt/disk{1...2} \
http://node2/mnt/disk{1...2} \
http://node3/mnt/disk{1...2} \
http://node4/mnt/disk{1...2}
- 路径中的
{1...2}是 MinIO 自解析语法，等价于写两次/mnt/disk1 /mnt/disk2 - 务必确保
/mnt/disk*是 XFS 或 ext4 格式，且已挂载、有读写权限（chown -R 1001:1001 /mnt/disk*） - 若用 systemd 托管，
ExecStart中不能换行，需写成单行或用\续行，否则 systemctl 会截断参数
访问集群时必须用负载均衡器，不能直连单节点
MinIO 集群所有节点对外暴露相同 API，但内部对象分布由纠删码算法决定——某个 PUT /bucket/key 可能只写入 node2/node3/node4/node1 的特定盘，下次 GET 若打到 node1 却没命中本地副本，它会主动从其他节点拉取再返回。这种跨节点代理会显著增加延迟，且破坏一致性语义。
- 必须前置一层四层 TCP 负载均衡（如 HAProxy、Nginx stream、云厂商 NLB），目标端口 9000，健康检查用
TCP connect即可（MinIO 无 HTTP 健康接口） - 禁止使用七层 HTTP 负载均衡做路径转发，MinIO 签名认证头（
Authorization,X-Amz-Date）对 Host 和路径敏感，中间件改写会导致签名失效 - 客户端 SDK 初始化时，
endpoint应指向 LB 地址（如https://minio.example.com），而非某台 node 的 IP
扩容只能加节点组，不能单独加盘或升级单节点
MinIO 集群一旦初始化完成，erasure set 大小即锁定。你无法在运行中给 node1 新增第三块盘，也不能把 node2 升级到新版本后重启——整个集群必须统一滚动升级，且所有节点二进制版本号必须严格一致（包括 patch 版本，如 RELEASE.2024-05-20T22-19-16Z）。
- 横向扩容唯一方式：停机，新增一组 N 个节点（N 同原集群节点数），重新运行
minio server命令，包含旧节点 + 新节点路径 - 升级前必须确认所有节点时间同步（
chrony或systemd-timesyncd），误差 > 15 秒会导致签名拒绝 - 首次启动后，MinIO 会自动执行
healing过程重建冗余，期间仍可读写，但性能下降明显，建议避开业务高峰
纠删码集群的“高性能”体现在吞吐而非低延迟——它适合海量小文件归档、备份镜像、CI 构建产物存储这类顺序写+批量读场景；如果业务要求 sub-10ms 的单 Key GET 延迟，就得接受单节点部署 + 多副本同步复制的架构，或者换用 Ceph RGW。
