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