扩容为什么不能随便加盘
分布式对象存储的数据分布规则在集群初始化时就确定了：一组磁盘分成集合，对象按分片规则落在集合内部。因此扩容的标准做法是新增一个同构的集合并入集群，而不是往某个已有集合里塞几块盘。新集合加入后主要承接新写入的数据，已有数据不会自动搬运，于是集群里会长期存在「新旧容量并存」的状态。
基本信息
| 扩容单位 | 整组新增，新增组的磁盘数量需与既有组一致 |
|---|---|
| 数据迁移 | 默认不自动迁移存量数据，需要显式触发均衡 |
| 容量口径 | 可用容量为各组之和，但单组写满会影响写入 |
| 前置条件 | 各节点时间同步、版本一致、磁盘布局规范 |
典型使用场景
- 容量告警后扩容：使用率接近水位线时新增一组磁盘
- 性能瓶颈：写入集中导致单组打满，需要增加并行度
- 业务增长预测：按季度增长曲线提前规划扩容批次
- 淘汰旧设备：以新增组替代老旧节点并逐步下线
- 跨站点扩展：为副本方向增加独立集群而非在原有集群内加盘
扩容前后核对
扩容前后核对
mc admin info myminio # 记录扩容前的节点、磁盘与使用率
# 按同构规格准备新节点与新磁盘，数量与既有组保持一致
# 使用包含新老节点的完整布局参数重启集群（参数以官方文档为准）
minio --version # 确认所有节点版本一致
mc admin info myminio # 核对新组是否被识别、容量是否增加
mc admin rebalance start myminio # 需要时触发存量数据再均衡常见扩容误区
| 做法 | 后果 | 正确方式 |
|---|---|---|
| 向已有组加盘 | 布局不一致，启动失败或数据分布异常 | 新增同构整组 |
| 新增组磁盘数不同 | 容量与纠删比例失衡 | 数量与规格与既有组保持一致 |
| 扩容后不均衡存量 | 老组持续满、新组空闲 | 按需触发再均衡 |
| 扩容与修复同时进行 | IO 竞争，两者都变慢 | 先完成修复再扩容 |
实施建议
- 扩容窗口安排在业务低谷，并提前评估网络与供电余量
- 扩容后先做小规模写入验证，确认新组真正参与数据分布
- 把再均衡当作有代价的操作：它会占用带宽与磁盘 IO
- 监控要同时看单组使用率，而不是只看集群总体使用率
- 扩容记录纳入配置管理，后续排障时能还原当时的布局
集群总体使用率不高但写入失败，往往是个别组已被写满；容量判断要下沉到组与磁盘维度。
扩容涉及重启服务与布局变更，属于高风险操作；执行前保留完整配置与前一次成功的启动参数，确保可以回退。