企业官网建设流程全解析

Silo节点退役与数据再平衡：如何安全下线集群节点并完整迁移数据而不丢数据

【免费下载链接】siloS3-Compatible Object Storage. A MinIO fork maintained by PGSTY项目地址: https://gitcode.com/gh_mirrors/minio5/silo

Silo 节点退役（Decommission）是分布式对象存储运维的核心操作：它能把老旧池中全部数据自动迁移到新池，让你安全下线节点而不丢数据。本文介绍 Silo 集群节点退役与数据再平衡（Rebalance）的完整流程、状态监控与回退方法，并给出防丢数据的校验清单。

为什么退役比直接拔盘更安全？

在分布式 Silo 中，磁盘按"池（Pool）"组织，每个对象写入一个编码集（Erasure Set），数据被切分并冗余分布在多块盘上。直接关机或删除旧池的命令行参数会导致数据丢失或不可读。

节点退役机制的安全保证来自 docs/distributed/DECOMMISSION.md 中描述的三个特性：

• 读不断流：处于退役中的池仍然允许读取全部旧数据，只有新写入会被自动调度到未退役的池；
• 版本顺序保真：带版本控制的桶迁移后，各对象的版本顺序保持不变；
• 可断点续传：即使集群中途重启导致退役被打断，再次启动后会从上次位置继续，而不是从头再来。

换句话说：旧池进入"排空（Draining）"状态后，系统按桶、按前缀、按对象逐个把数据搬迁到其余池，直到旧池容量归零并显示Complete，此时才能把它从启动命令中移除。

退役前的必要准备：先扩容新池

⚠️ 黄金法则：先扩池，再退役。目标池中必须有足够空间承接全部数据，否则迁移会失败。

以 4 节点池扩容为例，原集群为：

silo server http://host{1...4}/export{1...16}

新增第二个池（每池必须与原池使用相同的纠删奇偶配置）：

silo server http://host{1...4}/export{1...16} http://host{5...8}/export{1...16}

重启后新对象会自动按各池剩余空间比例分配。扩容操作是即时且不中断业务的，详见 docs/distributed/README.md。

仓库中的 docs/distributed/decom.sh 是一套完整的退役回归测试脚本，演示了"扩容 → 启动退役 → 等待 Complete → 摘除旧池 → 用diff和 MD5 校验核对对象清单"的全过程，非常值得借鉴作为你自己的验收流程。

一键启动节点退役（Decommission）

准备好新池后，用mc客户端启动退役。注意：退役的对象是池，命令行中要用池对应的完整地址通配符：

mc admin decommission start alias/ http://host{5...8}/export{1...16}

• 参数必须与服务器启动命令中该池的写法完全一致，否则会报"池未处于退役状态"；
• 一次只退役一个池，规划好节奏，不要把它当成日常操作。

实时查看退役进度与速率

不带参数时，status列出所有池的容量与状态：

mc admin decommission status alias/ ┌─────┬─────────────────────────────────┬──────────────────────────────────┬────────┐ │ ID │ Pools │ Capacity │ Status │ ├─────┼─────────────────────────────────┼──────────────────────────────────┼────────┤ │ 1st │ http://host{1...4}/export{1...16}│ 439 GiB (used) / 561 GiB (total) │ Active │ │ 2nd │ http://host{5...8}/export{1...16}│ 329 GiB (used) / 421 GiB (total) │ Draining │ └─────┴─────────────────────────────────┴──────────────────────────────────┴────────┘

针对正在退役的池，会看到实时速率与剩余量：

mc admin decommission status alias/ http://host{5...8}/export{1...16} Decommissioning rate at 36 MiB/sec [4 TiB/50 TiB] Started: 1 minute ago

状态机只有几种合法取值：Active（正常）→Draining（退役中）→Complete（迁移完成，可摘除）；中途取消则为 Draining(Canceled)，出错为 Draining(Failed)。进度、字节数、失败计数等字段定义在 cmd/erasure-server-pool-decom.go 的PoolDecommissionInfo结构中，排障时可对照。

退役太猛影响业务？随时暂停与恢复

如果迁移带宽占用过高，可以取消当前退役：

mc admin decommission cancel alias/ http://host{5...8}/export{1...16}

取消后池变为Draining(Canceled)。注意：取消不会让池回到 Active 状态，因为部分命名空间可能已散落在其他池；之后重新执行decommission start即可从断点继续。失败（Failed）的退役同样用start重启。

状态到达 Complete 之后：正式摘除旧池

Complete表示旧池数据已全部搬空，现在可以安全地从 Silo 启动参数中删掉该池：

• 裸机/系统服务部署：编辑MINIO_VOLUMES，去掉该池参数，然后并行重启所有节点，例如systemctl restart silo（服务单元见 silo.service）；
• Kubernetes 直管 StatefulSet：修改 Silo 容器命令行后执行kubectl apply；
• Operator 管理：把tenant.yaml的pools:从两个条目改为一个，再kubectl apply。

⚠️ 任何处于 Active 或 Draining 状态的池不允许从命令行中移除——请务必等到 Complete。

退役期间建议同时观察监控面板，确认新池容量增长、旧池下降，以及集群健康告警没有触发（参考 docs/metrics/prometheus/ 下的告警规则示例）。

节点退役（Decommission）vs 数据再平衡（Rebalance）怎么选？

Rebalance 的 API 入口（rebalance/start、rebalance/status、rebalance/stop）注册在 cmd/admin-router.go，状态结构与多池进度定义在 cmd/rebalance-admin.go。它与退役一样支持随时暂停、断点续传，状态语义一致。

退役后防丢数据的校验清单 ✅

摘除旧池后，建议执行以下核对，这也是 docs/distributed/decom.sh 自动化验收的做法：

1. 对象清单 diff：退役前mc ls -r --versions导出清单，退役后再次导出并diff，应为空；
2. 内容抽检：对关键对象执行mc cat | md5sum与退役前记录比对；
3. 版本桶验证：mc version info确认版本控制仍生效，版本顺序未乱；
4. IAM 与策略：mc admin user list、mc admin policy list数量与之前一致（用户/策略是集群级元数据，不受退役影响）；
5. 分层（Tiering）核对：若桶启用了生命周期 Transition，确认已分层对象在新池与暖层中均完整（注意：当前版本中启用了 ILM Transition 的桶会被服务器拒绝退役，需先移除过渡策略，见 docs/distributed/DECOMMISSION.md）。

另有一个易被忽略的细节：空删除标记不会迁移（避免在新池留下空元数据），如果业务依赖删除标记占位，请提前评估。

小结：节点退役四步法

1. 扩池—— 新池容量 ≥ 旧池已用空间，奇偶配置一致；
2. 启动——mc admin decommission start alias/ <池地址>；
3. 盯状态——decommission status观察速率，必要时cancel再start；
4. 摘除—— 状态 Complete 后从启动命令移除旧池、重启集群，并按清单校验。

掌握这套流程后，硬件升级、机房迁移、节点缩容都可以在不中断业务、不丢数据的前提下平滑完成。更多原理与边界情况，请阅读 docs/distributed/DECOMMISSION.md 与分布式部署指南 docs/distributed/README.md。

【免费下载链接】siloS3-Compatible Object Storage. A MinIO fork maintained by PGSTY项目地址: https://gitcode.com/gh_mirrors/minio5/silo