Elasticsearch索引的分片分配Recovery使用講解

什麼是recovery？

在elasticsearch中，recovery指的是一個索引的分片分配到另外一個節點的過程，一般在快照恢復、索引複製分片的變更、節點故障或重啟時發生，由於master節點儲存整個叢集相關的狀態資訊，因此可以判斷哪些分片需要再分配及分配到哪個節點，例如：

• 如果某個主分片在，而複製分片所在的節點掛掉了，那麼master需要另行選擇一個可用節點，將這個主分片的複製分片分配到可用節點上，然後進行主從分片的資料複製。
  如果某個主分片所在的節點掛掉了，複製分片還在，那麼master會主導將複製分片升級為主分片，然後再做主從分片資料複製。
• 如果某個分片的主副分片都掛掉了，則暫時無法恢復，而是要等持有相關資料的節點重新加入叢集後，master才能主持資料恢復相關操作。

但是，recovery過程要消耗額外的資源，CPU、記憶體、節點間的網路頻寬等。可能導致叢集的服務效能下降，甚至部分功能暫時無法使用，所以，有必要了解在recovery的過程和其相關的設定，來減少不必要的消耗和問題。

減少叢集full restart造成的資料來回拷貝

有時候，可能會遇到es叢集整體重啟的情況，比如硬體升級、不可抗力的意外等，那麼再次重啟叢集會帶來一個問題：某些節點優先起來，並優先選舉出了主節點，有了主節點，該主節點會立刻主持recovery的過程。

但此時，這個叢集資料還不完整（還有其他的節點沒有起來），例如A節點的主分片對應的複製分片所在的B節點還沒起來，但主節點會將A節點的幾個沒有複製分片的主分片重新拷貝到可用的C節點上。而當B節點成功起來了，自檢時發現在自己節點儲存的A節點主分片對應的複製分片已經在C節點上出現了，就會直接刪除自己節點中“失效”的資料（A節點的那幾個複製分片），這種情況很可能頻繁出現在有多個節點的叢集中。

而當整個叢集恢復後，其各個節點的資料分佈，顯然是不均衡的（先啟動的節點把資料恢復了，後起來的節點內刪除了無效的資料），這時，master就會觸發Rebalance的過程，將資料在各個節點之間挪動，這個過程又消耗了大量的網路流量。所以，我們需要合理的設定recovery相關引數來優化recovery過程。

• 在叢集啟動過程中，一旦有了多少個節點成功啟動，就執行recovery過程，這個命令將master節點（有master資格的節點）和data節點都算在內。

gateway.expected_nodes: 3

• 有幾個master節點啟動成功，就執行recovery的過程。

gateway.expected_master_nodes: 3

• 有幾個data節點啟動成功，就執行recovery的過程。

gateway.expected_data_nodes: 3

當叢集在期待的節點數條件滿足之前，recovery過程會等待gateway.recover_after_time指定的時間，一旦等待超時，則會根據以下條件判斷是否執行recovery的過程：

gateway.recover_after_nodes: 3    # 3個節點（master和data節點都算）啟動成功
gateway.recover_after_master_nodes: 3  # 3個有master資格的節點啟動成功
gateway.recover_after_data_nodes: 3   # 3個有data資格的節點啟動成功

上面三個設定滿足一個就會執行recovery的過程。
如果有以下設定的叢集：

gateway.expected_data_nodes: 10
gateway.recover_after_time: 5m
gateway.recover_after_data_nodes: 8

此時的叢集在5分鐘內，有10個data節點都加入叢集，或者5分鐘後有8個以上的data節點加入叢集，都會啟動recovery的過程。

減少主副本之間的資料複製

如果不是full restart，而是重啟單個節點，也會造成不同節點之間來複制，為了避免這個問題，可以在重啟之前，關閉叢集的shard allocation。

PUT _cluster/settings
{
  "transient": {
    "cluster.routing.allocation.enable":"none"
  }
}

當節點重啟後，再重新開啟：

PUT _cluster/settings
{
  "transient": {
    "cluster.routing.allocation.enable":"all"
  }
}

這樣，節點重啟後，儘可能的從本節點直接恢復資料。但是在es1.6版本之前，既使做了以上措施，仍然會出現大量主副分片之間的資料拷貝，從面上看，這點讓人很不理解，主副分片資料是完全一致的，在節點重啟後，直接從本節點的副本重恢復資料就好了呀，為什麼還要再從主分片再複製一遍呢？原因是在於recovery是簡單的對比主副分片的segment file（分段檔案）來判斷哪些資料一致是可以本地恢復，哪些不一致的需要重新拷貝的。而不同節點的segment file是完全獨立執行的，這可能導致主副本merge的深度不完全一致，從而造成即使檔案集完全一樣，而產生的segment file卻不完全一樣。

為了解決這個問題，在es1.6版本之後，加入了synced flush（同步重新整理）新特性，對於5分鐘沒有更新過的shard，會自動synced flush一下，其實就是為對應的shard加入一個synced flush id，這樣在節點重啟後，先對比主副shard的synced flush id，就可以知道兩個shard是否完全相同，避免了不必要的segment file拷貝。

需要注意的是synced flush只對冷索引有效，對於熱索引（5分鐘內有更新的索引）無效，如果重啟的節點包含有熱索引，那還是免不了大量的拷貝。如果要重啟一個包含大量熱索引的節點，可以按照以下步驟執行重啟過程，可以讓recovery過程瞬間完成：

• 暫停資料寫入
• 關閉叢集的shard allocation
• 手動執行 POST /_flush/synced
• 重啟節點
• 重新開啟叢集的shard allocation
• 等待recovery完成，當叢集的health status是green後
• 重新開啟資料寫入

特大熱索引為何恢復慢

對於冷索引，由於資料不再更新（對於elasticsearch來說，5分鐘，很久了），利用synced flush可以快速的從本地恢復資料，而對於熱索引，特別是shard很大的熱索引，除了synced flush派不上用場，從而需要大量跨節點拷貝segment file以外，translog recovery可能是導致慢的更重要的原因。
我們來研究下這個translog recovery是什麼鬼！
當節點重啟後，從主分片恢復資料到複製分片需要經歷3個階段：

• 第一階段，對於主分片上的segment file做一個快照，然後拷貝到複製分片所在的節點，在資料拷貝期間，不會阻塞索引請求，新增的索引操作會記錄到translog中（理解為於臨時檔案）。
• 第二階段，對於translog做一個快照，此快照包含第一階段新增的索引請求，然後重放快照裡的索引操作，這個階段仍然不會阻塞索引請求，新增索引操作記錄到translog中。
• 第三階段，為了能達到主副分片完全同步，阻塞新索引請求，然後重放上一階段新增的translog操作。

由此可見，在recovery過程完成之前，translog是不能被清除掉的。如果shard比較大，第一階段會耗時很長，會導致此階段產生的translog很大，重放translog要比簡單的檔案拷貝耗時更長，因此第二階段的translog耗時也顯著的增加了。等到了第三階段，需要重放的translog可能會比第二階段更多。要命的是，第三階段是會阻塞新索引（寫入）請求的，在對寫入實時性要求很高的場合，這就會導致效能下降，非常影響使用者體驗。因此，要加快特大熱索引恢復速度，最好是參照上一節中的方式：

• 暫停資料寫入。
• 手動synced flush。
• 等待資料恢復完成後。
• 重新恢復資料寫入。

這樣就會把資料延遲影響降到最低。

歡迎斧正，that's all see also：[本文主要參考：Elasticsearch Recovery詳解]

(https://blog.csdn.net/u012450329/article/details/52881045) | [cat recovery]

(https://www.elastic.co/guide/en/elasticsearch/reference/current/cat-recovery.html) | [Indices Recovery]

(https://www.elastic.co/guide/en/elasticsearch/reference/current/recovery.html)

以上就是Elasticsearch索引的分片分配Recovery使用講解的詳細內容，更多關於Elasticsearch索引的分片分配Recovery 的資料請關注it145.com其它相關文章！