幹貨 | Elasticsearch 運維實戰常用指令清單

連結

球友回報的實戰問題：

關于es的運維相關的， 遇到一些問題！

第一個問題：是關于叢集遷移的，目前需要 針對20億的資料做遷移，如果檔案遷移，需要停機時間太久，除了重新灌入，不知 道有沒有更好的方式？

第二個問題：我們es叢集的讀寫都很頻繁，如何把控在互相不影響性能，目前情況是會有互相影響！

第三個問題：之前做版本更新，更新後部分分片不可用，但是不知道什麼原因導緻？

最後：就是關于資料的擴容，備份，高可用這方面...... 擴容其實 面對一個問題就是你之前的es  mapping 如何建， 如果這個沒規劃好，增加節點的意義也不大了

另外就是面對現在叢集狀态黃色和紅色，沒有體系化的思路去排查問題到底出在哪兒？

更多的是點對點去臨時解決，積累的知識是碎片化的。

的确，類似問題經常被問到，是時候整合梳理一下了。

1、叢集狀态非綠排查清單

1.1 叢集狀态的含義

紅色：至少一個主分片未配置設定成功；

黃色：至少一個副本分片未配置設定成功；

綠色：全部主&副本都配置設定成功。

1.2 排查實戰

1.2.1 檢視叢集狀态

GET _cluster/health

傳回狀态舉例："status" : "red", 紅色，至少一個主分片未配置設定成功。

1.2.2 到底哪個節點出現了紅色或者黃色問題呢？

GET _cluster/health?level=indices

如下的方式，更明快直接

GET /_cat/indices?v&health=yellow

GET /_cat/indices?v&health=red

找到對應的索引。

1.2.3 到底索引的哪個分片出現了紅色或者黃色問題呢？

GET _cluster/health?level=shards

1.2.4 到底什麼原因導緻了叢集變成紅色或者黃色呢？

GET _cluster/allocation/explain

傳回核心資訊解讀舉例：

"current_state" : "unassigned",——未配置設定

 "unassigned_info" : {

   "reason" : "INDEX_CREATED",——原因，索引建立階段

   "at" : "2020-01-29T07:32:39.041Z",

   "last_allocation_status" : "no"

 },

 "explanation" : """node does not match index setting [index.routing.allocation.require] filters [box_type:"hot"]"""

       }

根本原因，shard分片與節點過濾類型不一緻 到此，找到了根本原因，也就知道了對應解決方案。

1.3 擴充思考：類似 "current_state" : "unassigned",——未配置設定 還有哪些？

實戰：

GET _cat/shards?h=index,shard,prirep,state,unassigned.reason

官網：

https://www.elastic.co/guide/en/elasticsearch/reference/7.2/cat-shards.html

未配置設定狀态及原因解讀：

（1）INDEX_CREATED

Unassigned as a result of an API creation of an index.

（2）CLUSTER_RECOVERED

Unassigned as a result of a full cluster recovery.

（3）INDEX_REOPENED

Unassigned as a result of opening a closed index.

（4）DANGLING_INDEX_IMPORTED

Unassigned as a result of importing a dangling index.

（5）NEW_INDEX_RESTORED

Unassigned as a result of restoring into a new index.

（6）EXISTING_INDEX_RESTORED

Unassigned as a result of restoring into a closed index.

（7）REPLICA_ADDED

Unassigned as a result of explicit addition of a replica.

（8）ALLOCATION_FAILED

Unassigned as a result of a failed allocation of the shard.

（9）NODE_LEFT

Unassigned as a result of the node hosting it leaving the cluster.

（10）REROUTE_CANCELLED

Unassigned as a result of explicit cancel reroute command.

（11）REINITIALIZED

When a shard moves from started back to initializing, for example, with shadow replicas.

（12）REALLOCATED_REPLICA

A better replica location is identified and causes the existing replica allocation to be cancelled.

2、節點間分片移動

适用場景：手動移動配置設定分片。将啟動的分片從一個節點移動到另一節點。

POST /_cluster/reroute

{

 "commands": [

   {

     "move": {

       "index": "indexname",

       "shard": 1,

       "from_node": "nodename",

       "to_node": "nodename"

     }

   }

 ]

}

3、叢集節點優雅下線

适用場景：保證叢集顔色綠色的前提下，将某個節點優雅下線。

PUT /_cluster/settings

 "transient": {

   "cluster.routing.allocation.exclude._ip": "122.5.3.55"

 }

}

4、強制重新整理

适用場景：重新整理索引是確定目前僅存儲在事務日志中的所有資料也永久存儲在Lucene索引中。

POST /_flush

注意：這和 7.6 版本之前的同步重新整理（未來8版本+會廢棄同步重新整理）一緻。

POST /_flush/synced

5、更改并發分片的數量以平衡叢集

适用場景：

控制在叢集範圍内允許多少并發分片重新平衡。預設值為2。

   "cluster.routing.allocation.cluster_concurrent_rebalance": 2

6、更改每個節點同時恢複的分片數量

如果節點已從叢集斷開連接配接，則其所有分片将都變為未配置設定狀态。經過一定的延遲後，分片将配置設定到其他位置。每個節點要恢複的并發分片數由該設定确定。

   "cluster.routing.allocation.node_concurrent_recoveries": 6

7、調整恢複速度

為了避免叢集過載，Elasticsearch限制了配置設定給恢複的速度。你可以仔細更改該設定，以使其恢複更快。

如果此值調的太高，則正在進行的恢複可能會消耗過多的帶寬和其他資源，這可能會使叢集不穩定。

   "indices.recovery.max_bytes_per_sec": "80mb"

8、清除節點上的緩存

适用場景：如果節點達到較高的JVM值，則可以在節點級别上調用該API 以使 Elasticsearch 清理緩存。

這會降低性能，但可以使你擺脫OOM（記憶體不足）的困擾。

POST /_cache/clear

9、調整斷路器

适用場景：為了避免在Elasticsearch中進入OOM，可以調整斷路器上的設定。這将限制搜尋記憶體，并丢棄所有估計消耗比所需級别更多的記憶體的搜尋。

注意：這是一個非常精密的設定，你需要仔細校準。

 "persistent": {

   "indices.breaker.total.limit": "40%"

10、叢集遷移

适用場景：叢集資料遷移、索引資料遷移等。

方案一、 針對索引部分或者全部資料，reindexPOST _reindex

 "source": {

   "index": "my-index-000001"

 "dest": {

   "index": "my-new-index-000001"

方案二：借助第三方工具遷移索引或者叢集

elasticdump

elasticsearch-migration

工具本質：scroll + bulk 實作。

11、叢集資料備份和恢複

适用場景：高可用業務場景，定期增量、全量資料備份，以備應急不時之需。

PUT /_snapshot/my_backup/snapshot_hamlet_index?wait_for_completion=true

 "indices": "hamlet_*",

 "ignore_unavailable": true,

 "include_global_state": false,

 "metadata": {

   "taken_by": "mingyi",

   "taken_because": "backup before upgrading"

POST /_snapshot/my_backup/snapshot_hamlet_index/_restore

小結

文章開頭的幾個運維問題已經解決，其他性能相關的問題，後面會有另外的博文做梳理。

運維工作包羅萬象，文章内容隻是抛磚引玉，開了個頭。

牛逼的叢集運維需要結合可視化工具（如：kibana，cerebro，elastic-hd，Prometheus + grafana，結合業務自研工具如 阿裡雲Eyou等）能極大提高效率。

你的Elasticsearch 運維的經驗、心得、體會，歡迎留言交流，我們一起完善清單。

參考：

Elasticsearch 官方文檔

https://logz.io/blog/elasticsearch-cheat-sheet/

更多推薦：

嚴選 | Elasticsearch史上最全最常用工具清單

幹貨 | Elasticsearch Top10 監控名額