Elasticsearch删除阶段策略未删最后索引致别名冲突，索引阻塞求助

问题现象 #

当ILM删除阶段策略尝试删除最后一个索引时，该索引未被删除，且别名index被重复添加到新旧索引上，引发别名冲突，导致当前索引被阻塞。

执行GET _aliases返回结果：

{
  "index-000113" : {
    "aliases" : {
      "index" : { }
    }
  },
  "index-000114" : {
    "aliases" : { }
  },
  "index-000115" : {
    "aliases" : { }
  },
  "index-000116" : {
    "aliases" : {
      "index" : { }
    }
  }
}

集群环境 #

3节点集群：1主节点 + 2数据节点

临时解决方法 #

已通过手动移除重复别名解决：

POST _aliases
{
  "actions": [
    {
      "remove": {
        "index": "index-000113",
        "alias": "index"
      }
    }
  ]
}

关联分片活动记录 #

Kibana中最后的分片活动：

• index-000113
  • Shard: 0 / Replica
  • Recovery type: Peer
  • Done (node01 > node03)
• index-000113
  • Shard: 0 / Primary
  • Recovery type: Existing_store
  • Done (n/a > node03)

疑问 #

上述分片活动似乎与问题相关，但无法理解其含义。请问：

1. 该问题产生的原因是什么？
2. 有哪些彻底的解决方案？

原因分析 #

1. 分片恢复延迟阻塞ILM删除流程
   分片活动记录显示index-000113的主分片通过Existing_store在node03完成恢复（从本地存储加载），副本分片通过Peer从node01同步到node03完成恢复。这说明该索引的分片曾处于不可用状态，ILM执行删除阶段时会检查索引分片健康度——如果分片未完全恢复（未分配/恢复中），ILM会暂停删除流程等待分片状态正常。
   但此时ILM滚动阶段已完成，新索引index-000116已创建并绑定别名index，旧索引因分片恢复延迟未被删除，最终导致同一别名绑定到多个索引上，引发冲突。

2. ILM阶段与分片健康检查的竞态条件
   ILM滚动阶段创建新索引并绑定别名后，删除阶段需要删除旧索引，但如果旧索引分片此时正处于恢复/重新分配过程中，ILM会判定索引不健康，跳过删除操作。而别名绑定逻辑已执行完毕，最终造成别名冲突。

解决方案 #

1. 优化ILM策略配置

• 在删除阶段添加分片分配等待时间，确保分片完成恢复后再执行删除：

  PUT _ilm/policy/your_policy
  {
    "policy": {
      "phases": {
        // 其他阶段配置
        "delete": {
          "actions": {
            "delete": {
              "wait_for_shard_allocations": "5m" // 根据集群规模调整时长
            }
          }
        }
      }
    }
  }
  

• 滚动阶段配置匹配集群节点的副本数，避免分片分配延迟：

  "hot": {
    "actions": {
      "rollover": {},
      "allocate": {
        "number_of_replicas": 1, // 2个数据节点对应1个副本
        "include": {},
        "exclude": {}
      }
    }
  }
  

2. 集群层面优化分片分配

• 调整分片恢复参数，提升恢复效率：

  PUT _cluster/settings
  {
    "persistent": {
      "cluster.routing.allocation.node_concurrent_recoveries": 2, // 增加并发恢复数
      "indices.recovery.max_bytes_per_sec": "100mb" // 提高恢复带宽上限
    }
  }
  

• 确保节点CPU、内存、磁盘IO资源充足，避免资源瓶颈导致分片恢复缓慢。

3. 自动化处理别名冲突

• 创建Watcher监控别名状态，当同一别名绑定多个索引时自动清理旧索引的别名：

  PUT _watcher/watch/alias_conflict_watch
  {
    "trigger": {
      "schedule": {
        "interval": "1m"
      }
    },
    "input": {
      "http": {
        "request": {
          "method": "GET",
          "path": "_aliases"
        }
      }
    },
    "condition": {
      "script": {
        "source": """
          def aliasIndices = [:];
          ctx.payload.each { index, data ->
            data.aliases.each { alias, _ ->
              if (!aliasIndices.containsKey(alias)) aliasIndices[alias] = [];
              aliasIndices[alias].add(index);
            }
          };
          return aliasIndices.any { alias, indices -> indices.size() > 1 };
        """
      }
    },
    "actions": {
      "fix_alias_conflict": {
        "transform": {
          "script": {
            "source": """
              def actions = [];
              def aliasIndices = [:];
              ctx.payload.each { index, data ->
                data.aliases.each { alias, _ ->
                  if (!aliasIndices.containsKey(alias)) aliasIndices[alias] = [];
                  aliasIndices[alias].add(index);
                }
              };
              aliasIndices.each { alias, indices ->
                if (indices.size() > 1) {
                  def sortedIndices = indices.sort().reverse();
                  sortedIndices[1..-1].each { oldIndex ->
                    actions.add({remove: {index: oldIndex, alias: alias}});
                  }
                }
              };
              return [actions: actions];
            """
          }
        },
        "http": {
          "request": {
            "method": "POST",
            "path": "_aliases",
            "body": "{{ctx.payload}}"
          }
        }
      }
    }
  }
  

4. 根源排查与复盘

• 检查集群日志中index-000113分片异常的原因（节点宕机、磁盘故障、网络中断等），从根源避免分片不可用。
• 定期查看ILM策略执行日志（GET _ilm/policy/your_policy?verbose），确认各阶段执行状态，提前发现潜在问题。

内容的提问来源于stack exchange，提问作者feroe