elasticsearch 的 reroute 操作本质是“先复制后删除”，若迁移中途失败（如目标节点宕机），已传输的部分数据会被自动清理，源分片保持完整，确保数据零丢失。
elasticsearch 的 reroute 操作本质是“先复制后删除”，若迁移中途失败（如目标节点宕机），已传输的部分数据会被自动清理，源分片保持完整，确保数据零丢失。
在 Elasticsearch 中，使用 _cluster/reroute API 手动触发分片重分配（例如将一个 20GB 的主分片从 nodeA 迁移至 nodeB）时，该过程并非直接移动（move）文件，而是安全的复制-验证-清理流程：
- 复制阶段（Copy）：ES 将源分片的全部数据（包括段文件、事务日志 translog 等）完整复制到目标节点的本地磁盘；
- 同步与校验阶段（Sync & Validate）：目标节点完成数据恢复后，会与主分片进行一致性校验（如检查 segment checksum、translog 起始偏移等），确保副本（此处为新主分片）状态可达且数据完整；
- 清理阶段（Delete）：仅当校验通过、集群状态更新成功（即 shard state 切换为 STARTED 并从 nodeA 的分片列表中移除）后，ES 才会异步删除 nodeA 上的原始分片数据。
⚠️ 关键点：整个过程具有原子性保障。若迁移中发生任何中断（如 nodeB 宕机、网络中断、磁盘满、JVM OOM 等），Elasticsearch 会：
- 立即中止 reroute 请求；
- 主动清除 nodeB 上已写入但未完成校验的临时分片目录（通常位于 path.data/nodes/0/indices/
/ / 下的 recovering-* 或未命名临时目录）； - 保持 nodeA 上原始分片完整、可服务，集群状态回滚至迁移前，_cat/shards 中该分片仍显示为 STARTED 且位于原节点。
✅ 因此，你无需担心“残留腐化数据”问题——Elasticsearch 不会保留部分写入的不一致分片。重启 nodeB 后，它只会作为普通节点参与后续分片分配（如你再次发起 reroute 或触发自动均衡），而不会尝试恢复或加载之前中断的半成品分片。
? 补充建议（尤其在无副本场景下）：
- 生产环境严禁长期运行零副本集群：单点故障即导致数据不可用，且无容灾能力；
- 大分片（如 20GB+）迁移耗时长、失败风险高，建议提前设置 cluster.routing.allocation.node_concurrent_recoveries: 1 和 indices.recovery.max_bytes_per_sec: 40mb 控制资源占用；
- 可通过 GET _cluster/allocation/explain?pretty 实时诊断分片无法分配的原因；
- 迁移前执行 POST /_flush 确保 translog 持久化，降低恢复开销。
总之，Elasticsearch 的分片重分配设计以数据安全为第一优先级：宁可重试，绝不妥协一致性。
