Elasticsearch 中 Delete index是否会导致节点离线

本篇文章为大家展示了Elasticsearch 中 Delete index是否会导致节点离线，内容简明扼要并且容易理解，绝对能使你眼前一亮，通过这篇文章的详细介绍希望你能有所收获。

先前朋友告诉我在他的集群中 Delete 一个 index 的时候，导致持有该 index 的节点从集群中离线，并且这种情况在可以某种条件下稳定复现，两者看起来没有直接关系，实际上是因为 Elasticsearch 7.x 中的一个新的机制。

master 发布集群状态时，等待其他节点应用集群状态，超时时间为 cluster.publish.timeout，默认30秒，如果某个节点超过这个时间仍然没有返回响应，这个节点被认为是  lagging 的节点，如果在 cluster.follower_lag.timeout 默认90秒内仍然没有追赶上 master 的集群状态，则将该节点从集群中移除。

在移除节点时，会有如下 INFO 级别的日志：

node [{node-1}] is lagging at cluster state version [0], although publication of cluster state version [87] completed [1.5m] ago

node-left[{node-1} lagging], term: 8, version: 89, reason: removed {{node-1}}

节点应用集群状态缓慢，可能是单次执行缓慢，超过了 cluster.follower_lag.timeout时间，也可能是多个应用集群状态过程都比较缓慢，导致缓慢的原因除了节点GC 之外，还可能和锁有关，对应到本文的主题，删除索引时会触发 Engine的 close 过程，这个过程需要加一把读写锁，而这把锁在refresh、flush、以及 recovery 的部分阶段等都会用到。因此如果这些过程异常缓慢，就可能会导致应用集群状态时因为等待锁而长时间阻塞，达到超时时间后被 master 踢出集群。

以 7.4 版本为例，在 soft-delete 开启的情况下，如果对文档有很多 update操作会导致 refresh 非常缓慢，此时 Delete index 或者 Close index 就会导致 master 将持有该索引的节点从集群中移除。

节点离线的代价是比较大的，当他重新加入集群，需要经历一个较长的 recovery 时间，按理说一个索引操作不应该导致集群拓扑方面的影响，但是从集群协调层面来说如果节点长时间不响应，将它踢出集群也无可厚非。这是集群协调层和控制指令耦合在一起的结果。HBase在实现类似功能的时候是 master 直接发一个 RPC过去要求节点关闭 region（类似 es 里的 shard），等他关闭完成后再更新集群元数据。如果节点长时间不返回响应，虽然不会导致节点离线，却容易产生状态不一致等问题，工程实现起来一不小心就有 bug。es 实现机制简单，出错少，只是效率低一些，有问题时容易产生连锁反应。

上述内容就是Elasticsearch 中 Delete index是否会导致节点离线，你们学到知识或技能了吗？如果还想学到更多技能或者丰富自己的知识储备，欢迎关注亿速云行业资讯频道。