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是否會導致節點離線，你們學到知識或技能了嗎？如果還想學到更多技能或者豐富自己的知識儲備，歡迎關注億速云行業資訊頻道。