停止启动具有所有主分片的弹性搜索实例答案

【问题标题】：Stop-start an elasticsearch instance having all the primary shards停止启动具有所有主分片的弹性搜索实例
【发布时间】：2020-02-20 07:08:57
【问题描述】：

我有一个包含 3 个节点的 Elasticsearch (v5.6.10) 集群。

节点 A：主节点
节点 B：主 + 数据
节点 C：主 + 数据

每个数据节点有 6 个分片，复制设置为 1。所有 6 个主节点都在节点 B 中，所有 6 个副本都在节点 C 中。

我的要求是取出节点 B，做一些维护工作，然后将其放回集群中，而不需要任何停机时间。

我查看了弹性文档、论坛和 stackoverflow 问题。我发现我应该先执行以下请求，以便将该节点上的分片分配给其余节点。

curl -XPUT localhost:9200/_cluster/settings -H 'Content-Type: application/json' -d '{
  "transient" :{
      "cluster.routing.allocation.exclude._ip" : <Node B IP>
   }
}';echo

重新分配所有分片后，我可以关闭节点并进行维护工作。完成后，我必须再次包含节点以进行分配，Elasticsearch 将再次重新平衡分片。

现在我还发现了另一个讨论，其中用户面临黄色/红色集群健康问题，因为只有一个数据节点但错误地将复制设置为一个，导致未分配的分片。在我看来，在做这个练习时，我正在将我的集群带向那个状态。

所以，我关心的是我是否遵循了正确的方法，记住我的所有主分片都在我从复制因子为 1 的集群中取出的节点（节点 B）中。

【问题讨论】：

标签： elasticsearch

【解决方案1】：

只有两个数据节点并且您想关闭一个，您无法真正重新分配分片。 Elasticsearch 从不在同一个节点上分配主分片和副本分片；它不会增加可用性或性能方面的任何好处，只会使磁盘空间增加一倍。所以你的重新分配命令不会在这里增加任何好处，因为分片不能移动到任何地方。
执行synced flush，然后执行orderly shutdown of the node。剩余节点上的副本分片将自动提升为主分片。在另一个节点再次加入之前，您的集群将变黄，但在您的场景中并没有真正的解决方法（既不是黑客也不是矫枉过正）。但这很好 - 只要您始终有一个副本，它就会在另一个节点上，并且您的集群将继续按预期工作。

【讨论】：

感谢您的指导。不过还有一个问题。我知道一个 Kibana 实例正在节点 B 上运行。因此，在节点 B 中有一个 .kibana 索引的主分片，在节点 C 中有相应的副本。一旦我取出节点 B，节点中的所有副本分片C 将被提升为主要的，包括 .kibana 之一。现在当我再次加入节点 B 时，它将保存副本分片，因此 Kibana 现在将指向 .kibana 索引的副本副本而不是主索引。会不会有什么问题？
还有一件事，因为弹性不会有任何停机时间，它会继续获取索引请求，这里同步刷新有什么用吗？
Kibana 或任何其他应用程序不需要关心主分片或副本分片。每个请求都由一个所谓的协调节点（所有节点之间的循环）处理，并将其转发到正确的分片。
同步刷新应该仍然有帮助，因为您至少有一个最近的检查点可以构建。没有任何写入，恢复会更快；特别是因为您的 Elasticsearch 版本太旧以至于它还没有序列 ID。但它仍然可以工作并且不会造成任何停机时间；只是恢复需要更长的时间。
感谢您的解释。但是我在运行 Kibana 的 Elasticsearch 集群中没有任何专用的协调节点，而是在节点 B（主 + 数据）中运行。所以这不会对我的情况造成任何问题。