es 集群半数以上master节点掉线解决方法

es版本

概念介绍

介绍处理方法前介绍几个es的基础概念，方便理解解决方法。

1.es集群有元数据（clusterstate）包含cluster、index、shard级别的元数据，持久化保存在master-eligible节点

2.es集群第一次启动时称为bootstrap，该过程将配置文件中的cluster.initial_master_node作为初始的投票节点（Voting configurations），投票节点具有选举master和commit cluster state的权利，超过半数以上同意即投票成功。

3.使用UUID作为节点和集群的唯一表示，每个节点都会持久化当前集群的UUID

4.投票节点（Voting configurations）会变化，保证集群容错能力最大并且不会脑裂。假如现在投票节点有3个，加入了两个master-eligible节点，那么投票节点就会有5个，如果掉线了一个投票节点还是3个，数量会保持为奇数

情景一

大于等于qorum数量节点掉线，但仍有master-eligible节点存活

---

由于集群中投票节点永远不可能达到qorum，所以集群无法选主，但所幸cluster state还有一份。

1. 使用bin/elasticsearch-node unsafe-bootstrap命令让唯一主节点以不安全的方式改写投票节点，就像重新进行bootstrap一样，自己使用持久化的cluster state形成一个新集群
2. 其他数据节点无法加入新集群因为UUID不同，使用bin/elasticsearch-node detach-cluster命令让节点离开之前的集群
3. 启动数据节点和新的master-eligible节点，他会加入新集群中。

情景二

所有master-eligible节点掉线

---

我们已经没有clsuter state了，唯一的希望是数据节点上的index数据

1. 启动足够的master-eligible节点形成一个新集群
2. 使用gateway.auto_import_dangling_indices: true配置启动数据节点。或者，启动数据节点并使用Import dangling indexAPI将index数据import到cluster state中。官方推荐后者
3. 这些index可以正常查询了

注意事项

使用dangling只能恢复index和shard元数据，cluster setting和alias等数据无法恢复，如果集群有重名index也无法成功import，比如.security7是安全相关的内部索引，也无法恢复

 

我们详细解释图中这两种方式的具体操作。

🔧 方法一：手动使用“导入悬空索引”API（推荐）

这是官方推荐的方式，因为它让你对恢复过程有完全的控制权，可以决定导入哪些索引。

1. 组建新集群：

   • 首先，你需要启动足够数量（例如3个）的、纯净的（确保数据目录为空或为新配置的）Master-eligible节点。确保它们的 cluster.name 配置一致，并能相互发现，形成一个健康的新集群（状态为 green 或 yellow）。

2. 启动数据节点：

   • 在你的数据节点上，不要设置 gateway.auto_import_dangling_indices，或者确保其值为 false（默认就是 false）。

   • 启动一个数据节点。启动后，它应该能自动加入到上一步创建的新集群中。此时，它磁盘上的索引由于没有在新集群的集群状态中注册，会被标记为“悬空索引”。

3. 发现并导入悬空索引：

   • 使用以下API列出该节点上所有的悬空索引：

     bash

     GET /_cat/indices?v&health=red

   • 找到你需要恢复的索引名后，使用“导入悬空索引”API将其手动加入到集群状态中：

     bash

     POST /_dangling/<index_uuid>?accept_data_loss=true

     注意：这里的 <index_uuid> 是索引的UUID，不是索引名称。你可以通过 GET /_cat/indices/<index_name>?v 并查看 uuid 列来获取。

   • 执行后，该索引会开始恢复，并最终变为可查询状态。

4. 重复操作：

   • 对每个数据节点上的每个需要恢复的索引，重复步骤2和3。建议逐个节点、逐个索引操作，便于观察和排除问题。