MinIO AIStor 分布式存储：纠删码、Server Pool、扩容与故障恢复
按当前 MinIO AIStor 文档，讲清对象、Erasure Set 和 Server Pool，以及读写仲裁、扩容、换盘与灾备的边界。
MinIO 集群容量不够时，很多人的第一反应是：给现有机器再插几块盘。
这在普通文件系统里很自然，在 MinIO 的分布式拓扑里却不是标准扩容方式。要解释原因，需要先分清三个层次：对象怎样变成数据块，数据块落在哪个 Erasure Set，以及若干 Erasure Set 怎样组成 Server Pool。
本文以 2026 年 7 月的 MinIO AIStor 文档为准。旧版或其他发行形态的配置入口和操作流程可能不同，生产变更仍要对照实际版本。
这三个概念混在一起，扩容、换盘和灾备都会做错。
对象不是完整复制到每台机器
一个对象写入 MinIO 后，会按照 Reed-Solomon 纠删码拆成数据分片和校验分片，再分散到同一个 Erasure Set 的多块盘上。
可以把它写成：
N = K + MK 是数据分片数，M 是校验分片数，N 是这个 Erasure Set 的条带宽度。读取对象时，只要仍有足够分片满足读仲裁，系统就能重建原始内容。少量磁盘损坏后，校验分片也能参与修复。
这和“三副本”不是一回事。副本方案保存多份完整对象，思路直观，但原始容量开销较大；纠删码把冗余变成校验分片，容量利用率通常更高，代价是写入、读取降级和修复都需要更多计算与跨盘 I/O。
在当前 MinIO AIStor 文档中，Erasure Set 的数量和宽度会在 Server Pool 初始化时确定，具体支持范围随版本和配置变化。更重要的事实是：初始化完成后，不能随意修改这组布局。
仲裁决定“坏几块盘以后还能做什么”
工程上最危险的一句话是“EC:4 所以可以随便坏四块盘”。
容错要看坏盘是否集中在同一个 Erasure Set，也要区分读和写。其他 Pool 还有很多空闲盘，并不能替一个已经丢失仲裁的 Erasure Set 投票。
对于用 N = K + M 表示的对象，至少要保留足够分片才能读取。写入还要满足写仲裁；当校验分片占到条带的一半时，MinIO 为避免两个“半边”分别接受同一个对象的写入，写仲裁会比读仲裁多一个。
所以监控不能只看“全局还有多少块健康盘”，还要看：
- 故障落在哪个 Erasure Set；
- 当前对象的 parity 设置；
- 读仲裁和写仲裁是否仍然成立；
- 修复期间是否又出现同一故障域内的新故障；
- 集群是否已经从可读写退化为只读，或彻底丢失仲裁。
一旦对象失去读仲裁，纠删码本身无法凭空恢复内容。此时只能依赖站点复制、其他备份或上游数据重建。
Server Pool 是容量扩展和故障边界的一部分
一组 MinIO server 进程及其磁盘共同构成一个 Server Pool。多个 Pool 可以放在同一个集群命名空间下，客户端仍然通过同一套 S3 API 访问对象。
横向扩容的标准思路是追加新的 Server Pool，不是改变旧 Pool 的盘数，也不是扩大底层逻辑卷后期待 MinIO 自动识别新容量。新 Pool 还必须满足集群已有的纠删码 parity 要求。MinIO 不强制新旧 Pool 的硬件完全一样，但官方建议使用相近的节点、磁盘类型和性能配置，否则同一个命名空间里会出现明显不同的延迟和故障表现。
新增 Pool 后，历史对象不会自动平均搬过去。MinIO 会根据各 Pool 的可用空间比例，把后续写入更多地分配给空闲空间较大的 Pool；需要迁移历史数据时，可以按当前版本文档评估手动 rebalance。
这意味着扩容不是“加完容量，所有盘立刻一样满”。容量规划要提前做，给数据增长和修复留出余量，而不是等磁盘接近写满再临时拼一个 Pool。
按当前 AIStor 扩容文档，新增 Pool 后需要在相近时间重启集群内所有 Object Store 进程，并明确不建议逐节点滚动重启。官方将这套扩容流程设计为非中断 I/O，但生产操作仍应按所用版本验证客户端重试、负载均衡和就绪检查。
换盘是在恢复原拓扑，扩容是在增加新拓扑
坏盘更换和容量扩展看起来都在“加盘”，目标完全不同。
换盘要让新盘接替旧盘在原 Erasure Set 中的位置。当前 MinIO 文档要求替换盘为空盘、使用 XFS，并具备相同类型、相当或更高性能以及相当或更大容量。更大的替换盘不会让 Pool 容量自动变大，因为可用容量仍受 Pool 中最小磁盘约束。
挂载路径和磁盘标识也要稳定。MinIO 根据配置看到的是 endpoint，不知道管理员心里认为哪块盘是“新盘”。如果挂载错位、旧盘目录残留，系统可能把一个运维动作识别成完全不同的拓扑变化。
盘替换并重新挂载后，MinIO 会检测并修复新盘上的分片。修复会消耗磁盘、网络和 CPU，因此需要同时看 heal 进度、请求延迟、磁盘错误和剩余仲裁。当前版本在同一 Erasure Set 有多块盘需要修复时，会按顺序优先完成其中一块，避免多路修复长期争抢资源。
更换整台节点时，原则仍然一样：恢复相同的 endpoint、盘数和挂载布局，再让系统完成 healing。不要借节点故障顺便改变原 Pool 的形状。
Server Pool 不是灾备副本
多个 Pool 共用同一个命名空间，很容易让人误以为“一个 Pool 坏了，另一个自然接管”。MinIO 官方文档明确提醒，Pool 扩容不提供 BC/DR 级别的保护。
每个 Pool 内有独立的 Erasure Set，但完整丢失一个 Pool，可能使整个集群停止 I/O；某个 Erasure Set 丢失读仲裁时，其他 Pool 的空盘也无法还原那些对象。因此，Pool 解决的是单集群容量与硬件生命周期，不等同于异地灾备。
真正要抵御机房级故障、误删除扩大或整个集群不可用，需要另一个故障域中的站点复制或经过验证的外部备份。备份也不能停在“对象已经复制”这一步，还要定期验证版本、权限、加密密钥和恢复路径。
一套更稳的运维判断
遇到容量或硬件问题时，可以先问四个问题。
第一，这是坏盘恢复、节点替换、Pool 扩容，还是整站灾备？不要用一个操作解决四类问题。
第二，受影响对象所在的 Erasure Set 还剩多少仲裁？全局健康百分比对此帮助有限。
第三，这次动作是在恢复原拓扑，还是增加一个新 Pool？恢复原拓扑要保持 endpoint 和挂载关系，新增 Pool 则要按现有 parity 与容量计划设计。
第四，如果操作失败，数据从哪里恢复？答案不能只是“MinIO 有纠删码”。纠删码处理的是一定范围内的盘故障，越过读仲裁以后，仍要靠独立副本或备份。
把这些边界想清楚，MinIO 的扩容和恢复就不会再被简化成“多插几块盘”。