Elasticsearch 中 Delete index是否會導(dǎo)致節(jié)點離線

本篇文章為大家展示了Elasticsearch 中 Delete index是否會導(dǎo)致節(jié)點離線，內(nèi)容簡明扼要并且容易理解，絕對能使你眼前一亮，通過這篇文章的詳細(xì)介紹希望你能有所收獲。

先前朋友告訴我在他的集群中 Delete 一個 index 的時候，導(dǎo)致持有該 index 的節(jié)點從集群中離線，并且這種情況在可以某種條件下穩(wěn)定復(fù)現(xiàn)，兩者看起來沒有直接關(guān)系，實際上是因為 Elasticsearch 7.x 中的一個新的機制。

master 發(fā)布集群狀態(tài)時，等待其他節(jié)點應(yīng)用集群狀態(tài)，超時時間為 cluster.publish.timeout，默認(rèn)30秒，如果某個節(jié)點超過這個時間仍然沒有返回響應(yīng)，這個節(jié)點被認(rèn)為是  lagging 的節(jié)點，如果在 cluster.follower_lag.timeout 默認(rèn)90秒內(nèi)仍然沒有追趕上 master 的集群狀態(tài)，則將該節(jié)點從集群中移除。

在移除節(jié)點時，會有如下 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}}

節(jié)點應(yīng)用集群狀態(tài)緩慢，可能是單次執(zhí)行緩慢，超過了 cluster.follower_lag.timeout時間，也可能是多個應(yīng)用集群狀態(tài)過程都比較緩慢，導(dǎo)致緩慢的原因除了節(jié)點GC 之外，還可能和鎖有關(guān)，對應(yīng)到本文的主題，刪除索引時會觸發(fā) Engine的 close 過程，這個過程需要加一把讀寫鎖，而這把鎖在refresh、flush、以及 recovery 的部分階段等都會用到。因此如果這些過程異常緩慢，就可能會導(dǎo)致應(yīng)用集群狀態(tài)時因為等待鎖而長時間阻塞，達到超時時間后被 master 踢出集群。

以 7.4 版本為例，在 soft-delete 開啟的情況下，如果對文檔有很多 update操作會導(dǎo)致 refresh 非常緩慢，此時 Delete index 或者 Close index 就會導(dǎo)致 master 將持有該索引的節(jié)點從集群中移除。

節(jié)點離線的代價是比較大的，當(dāng)他重新加入集群，需要經(jīng)歷一個較長的 recovery 時間，按理說一個索引操作不應(yīng)該導(dǎo)致集群拓?fù)浞矫娴挠绊?，但是從集群協(xié)調(diào)層面來說如果節(jié)點長時間不響應(yīng)，將它踢出集群也無可厚非。這是集群協(xié)調(diào)層和控制指令耦合在一起的結(jié)果。HBase在實現(xiàn)類似功能的時候是 master 直接發(fā)一個 RPC過去要求節(jié)點關(guān)閉 region（類似 es 里的 shard），等他關(guān)閉完成后再更新集群元數(shù)據(jù)。如果節(jié)點長時間不返回響應(yīng)，雖然不會導(dǎo)致節(jié)點離線，卻容易產(chǎn)生狀態(tài)不一致等問題，工程實現(xiàn)起來一不小心就有 bug。es 實現(xiàn)機制簡單，出錯少，只是效率低一些，有問題時容易產(chǎn)生連鎖反應(yīng)。

上述內(nèi)容就是Elasticsearch 中 Delete index是否會導(dǎo)致節(jié)點離線，你們學(xué)到知識或技能了嗎？如果還想學(xué)到更多技能或者豐富自己的知識儲備，歡迎關(guān)注億速云行業(yè)資訊頻道。