Elasticsearch 分片重分配失败如何恢复数据

Elasticsearch 的 reroute 操作本质是“先复制后删除”，若迁移中途失败（如目标节点宕机），已传输的部分数据会被自动清理，源分片保持完整，确保数据零丢失。

Elasticsearch 的 reroute 操作本质是“先复制后删除”，若迁移中途失败（如目标节点宕机），已传输的部分数据会被自动清理，源分片保持完整，确保数据零丢失。

在 Elasticsearch 中，使用 _cluster/reroute API 手动触发分片重分配（例如将一个 20GB 的主分片从 nodeA 迁移至 nodeB）时，其底层行为并非直接“移动”（move），而是安全的两阶段复制流程：

1. 复制阶段（Copy）：ES 首先在目标节点（nodeB）上创建一个新的空分片目录，然后通过高效的段文件（segment files）流式拷贝方式，将源分片（nodeA）的全部 Lucene 索引数据逐步复制过去；
2. 校验与提交阶段（Validate & Commit）：复制完成后，ES 会对目标分片执行完整性校验（包括 checksum 验证、commit point 一致性检查等），确认所有段文件正确无误且可正常打开；
3. 清理阶段（Cleanup）：仅当校验完全通过，ES 才会向集群状态（Cluster State）提交变更，将该分片的分配信息更新为 nodeB，并异步删除 nodeA 上的原始分片数据。

⚠️ 关键点：整个过程具备原子性保障。若任一环节失败（如 nodeB 在复制中途宕机、磁盘满、网络中断或 JVM 崩溃），reroute 请求将超时失败；此时：

• nodeB 上残留的不完整分片目录会被 Elasticsearch 自动识别为“stale shard”并立即清除（通常在节点重启后由 ShardStateAction 或 IndicesService 触发清理）；
• nodeA 上的原始分片保持只读锁定状态，不受影响，持续提供服务；
• 集群状态中该分片仍标记为分配在 nodeA，不会出现“分裂脑”或数据不一致。

✅ 示例：你执行如下 reroute 请求

POST /_cluster/reroute
{
  "commands": [
    {
      "move": {
        "index": "my-index",
        "shard": 0,
        "from_node": "nodeA",
        "to_node": "nodeB"
      }
    }
  ]
}

若 nodeB 在传输 60% 数据后宕机，ES 将终止操作，nodeB 重启后会自动扫描并删除 /path/to/data/nodes/0/indices/.../0/ 下未完成初始化的临时分片目录；而 nodeA 的分片毫发无损，无需人工干预。

? 注意事项：

• 该机制依赖于 Elasticsearch 内置的容错设计，不要手动删除或修改 data 目录下的分片文件，否则可能破坏内部元数据一致性；
• 单分片无副本（即 number_of_replicas: 0）时，虽迁移更轻量，但也意味着零冗余容灾能力——务必确保迁移前源节点稳定，且建议在低峰期操作；
• 可通过 GET _cat/shards/my-index?v&s=node 实时观察分片分配状态，或监听 GET _cluster/allocation/explain 排查阻塞原因。

总之，Elasticsearch 的分片重分配是稳健、可恢复的设计：失败即回滚，无“中间态腐化数据”，你始终拥有完整的原始分片。