干貨 | Elasticsearch 運維實戰(zhàn)常用命令清單
背景
球友反饋的實戰(zhàn)問題：
關(guān)于es的運維相關(guān)的， 遇到一些問題！
第一個問題：是關(guān)于集群遷移的，目前需要 針對20億的數(shù)據(jù)做遷移，如果文件遷移，需要停機(jī)時間太久，除了重新灌入，不知 道有沒有更好的方式？ 第二個問題：我們es集群的讀寫都很頻繁，如何把控在相互不影響性能，當(dāng)前情況是會有相互影響！ 第三個問題：之前做版本升級，升級后部分分片不可用，但是不知道什么原因?qū)е拢?/section> 最后：就是關(guān)于數(shù)據(jù)的擴(kuò)容，備份，高可用這方面...... 擴(kuò)容其實?面對一個問題就是你之前的es ?mapping 如何建， 如果這個沒規(guī)劃好，增加節(jié)點的意義也不大了 另外就是面對現(xiàn)在集群狀態(tài)黃色和紅色，沒有體系化的思路去排查問題到底出在哪兒？
更多的是點對點去臨時解決，積累的知識是碎片化的。
的確，類似問題經(jīng)常被問到，是時候整合梳理一下了。
1、集群狀態(tài)非綠排查清單
1.1 集群狀態(tài)的含義
紅色：至少一個主分片未分配成功； 黃色：至少一個副本分片未分配成功； 綠色：全部主&副本都分配成功。
1.2 排查實戰(zhàn)
1.2.1 查看集群狀態(tài)
GET?_cluster/health
返回狀態(tài)舉例："status" : "red", 紅色，至少一個主分片未分配成功。
1.2.2 到底哪個節(jié)點出現(xiàn)了紅色或者黃色問題呢？
GET?_cluster/health?level=indices
如下的方式，更明快直接
GET?/_cat/indices?v&health=yellow
GET?/_cat/indices?v&health=red
找到對應(yīng)的索引。
1.2.3 到底索引的哪個分片出現(xiàn)了紅色或者黃色問題呢？
GET?_cluster/health?level=shards
1.2.4 到底什么原因?qū)е铝思鹤兂杉t色或者黃色呢？
GET?_cluster/allocation/explain
返回核心信息解讀舉例：
"current_state"?:?"unassigned",——未分配
??"unassigned_info"?:?{
????"reason"?:?"INDEX_CREATED",——原因，索引創(chuàng)建階段
????"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分片與節(jié)點過濾類型不一致 到此，找到了根本原因，也就知道了對應(yīng)解決方案。
1.3 擴(kuò)展思考：類似 "current_state" : "unassigned",——未分配 還有哪些？
實戰(zhàn)：
GET?_cat/shards?h=index,shard,prirep,state,unassigned.reason
官網(wǎng)：https://www.elastic.co/guide/en/elasticsearch/reference/7.2/cat-shards.html
未分配狀態(tài)及原因解讀：
（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、節(jié)點間分片移動
適用場景：手動移動分配分片。將啟動的分片從一個節(jié)點移動到另一節(jié)點。
POST?/_cluster/reroute
{
??"commands":?[
????{
??????"move":?{
????????"index":?"indexname",
????????"shard":?1,
????????"from_node":?"nodename",
????????"to_node":?"nodename"
??????}
????}
??]
}?
3、集群節(jié)點優(yōu)雅下線
適用場景：保證集群顏色綠色的前提下，將某個節(jié)點優(yōu)雅下線。
PUT?/_cluster/settings
{
??"transient":?{
????"cluster.routing.allocation.exclude._ip":?"122.5.3.55"
??}
}
4、強(qiáng)制刷新
適用場景：刷新索引是確保當(dāng)前僅存儲在事務(wù)日志中的所有數(shù)據(jù)也永久存儲在Lucene索引中。
POST?/_flush
注意：這和 7.6 版本之前的同步刷新（未來8版本+會廢棄同步刷新）一致。
POST?/_flush/synced
5、更改并發(fā)分片的數(shù)量以平衡集群
適用場景：
控制在集群范圍內(nèi)允許多少并發(fā)分片重新平衡。默認(rèn)值為2。
PUT?/_cluster/settings
{
??"transient":?{
????"cluster.routing.allocation.cluster_concurrent_rebalance":?2
??}
}
6、更改每個節(jié)點同時恢復(fù)的分片數(shù)量
適用場景：
如果節(jié)點已從集群斷開連接，則其所有分片將都變?yōu)槲捶峙錉顟B(tài)。經(jīng)過一定的延遲后，分片將分配到其他位置。每個節(jié)點要恢復(fù)的并發(fā)分片數(shù)由該設(shè)置確定。
PUT?/_cluster/settings
{
??"transient":?{
????"cluster.routing.allocation.node_concurrent_recoveries":?6
??}
}
7、調(diào)整恢復(fù)速度
適用場景：
為了避免集群過載，Elasticsearch限制了分配給恢復(fù)的速度。你可以仔細(xì)更改該設(shè)置，以使其恢復(fù)更快。
如果此值調(diào)的太高，則正在進(jìn)行的恢復(fù)可能會消耗過多的帶寬和其他資源，這可能會使集群不穩(wěn)定。
PUT?/_cluster/settings
{
??"transient":?{
????"indices.recovery.max_bytes_per_sec":?"80mb"
??}
}
8、清除節(jié)點上的緩存
適用場景：如果節(jié)點達(dá)到較高的JVM值，則可以在節(jié)點級別上調(diào)用該API 以使 Elasticsearch 清理緩存。
這會降低性能，但可以使你擺脫OOM（內(nèi)存不足）的困擾。
POST?/_cache/clear
9、調(diào)整斷路器
適用場景：為了避免在Elasticsearch中進(jìn)入OOM，可以調(diào)整斷路器上的設(shè)置。這將限制搜索內(nèi)存，并丟棄所有估計消耗比所需級別更多的內(nèi)存的搜索。
注意：這是一個非常精密的設(shè)置，你需要仔細(xì)校準(zhǔn)。
PUT?/_cluster/settings
{
??"persistent":?{
????"indices.breaker.total.limit":?"40%"
??}
}
10、集群遷移
適用場景：集群數(shù)據(jù)遷移、索引數(shù)據(jù)遷移等。
方案一、 針對索引部分或者全部數(shù)據(jù)，reindex
POST?_reindex
{
??"source":?{
????"index":?"my-index-000001"
??},
??"dest":?{
????"index":?"my-new-index-000001"
??}
}
方案二：借助第三方工具遷移索引或者集群
elasticdump elasticsearch-migration
工具本質(zhì)：scroll + bulk 實現(xiàn)。
11、集群數(shù)據(jù)備份和恢復(fù)
適用場景：高可用業(yè)務(wù)場景，定期增量、全量數(shù)據(jù)備份，以備應(yīng)急不時之需。
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
小結(jié)
文章開頭的幾個運維問題已經(jīng)解決，其他性能相關(guān)的問題，后面會有另外的博文做梳理。
運維工作包羅萬象，文章內(nèi)容只是拋磚引玉，開了個頭。
牛逼的集群運維需要結(jié)合可視化工具（如：kibana，cerebro，elastic-hd，Prometheus + grafana，結(jié)合業(yè)務(wù)自研工具如 阿里云Eyou等）能極大提高效率。
你的Elasticsearch 運維的經(jīng)驗、心得、體會，歡迎留言交流，我們一起完善清單。
參考：
Elasticsearch 官方文檔?
https://logz.io/blog/elasticsearch-cheat-sheet/?
更多推薦：
嚴(yán)選 | Elasticsearch史上最全最常用工具清單
干貨 | Elasticsearch Top10 監(jiān)控指標(biāo)
更短時間更快習(xí)得更多干貨！
中國近?1/4?的 Elastic認(rèn)證工程師出自于此！