集群狀態(tài)為什么會(huì)異常？

想知道這個(gè)，我們首先需要了解一下集群的幾種狀態(tài)。

Elasticsearch 集群健康狀態(tài)分為三種：

• GREEN
• YELLOW
• RED

GREEN是最健康的狀態(tài)，說(shuō)明所有的分片包括副本都可用。這種情況Elasticsearch集群所有的主分片和副本分片都已分配，Elasticsearch集群是100%可用的。

那么，集群狀態(tài)在什么情況下發(fā)生RED和YELLOW呢？

YELLOW：主分片可用，但是副本分片不可用。這種情況Elasticsearch集群所有的主分片已經(jīng)分配了，但至少還有一個(gè)副本是未分配的。不會(huì)有數(shù)據(jù)丟失，所以搜索結(jié)果依然是完整的。不過(guò)，集群高可用性在某種程度上會(huì)被弱化。可以把yellow想象成一個(gè)需要關(guān)注的warnning，該情況不影響索引讀寫(xiě)，一般會(huì)自動(dòng)恢復(fù)。

RED：存在不可用的主分片。此時(shí)執(zhí)行查詢雖然部分?jǐn)?shù)據(jù)仍然可以查到，但實(shí)際上已經(jīng)影響到索引讀寫(xiě)，需要重點(diǎn)關(guān)注。這種情況Elasticsearch集群至少一個(gè)主分片（以及它的全部副本）都在缺失中。這意味著索引已缺少數(shù)據(jù)，搜索只能返回部分?jǐn)?shù)據(jù)，而分配到這個(gè)分片上的請(qǐng)求都返回異常。

查看集群狀態(tài)

使用kibana開(kāi)發(fā)工具，查看集群狀態(tài)：

GET /_cluster/health

這里可以看到，當(dāng)前集群狀態(tài)為red，有9個(gè)未分配的分片

ES健康接口返回內(nèi)容官方解釋

問(wèn)題分析

當(dāng)集群狀態(tài)異常時(shí)，需要重點(diǎn)關(guān)注unassigned_shards沒(méi)有正常分配的分片，這里舉例說(shuō)明其中一種場(chǎng)景。

找到異常索引

查看索引情況，并根據(jù)返回找到狀態(tài)異常的索引

GET /_cat/indices

查看詳細(xì)的異常信息

GET /_cluster/allocation/explain

這里通過(guò)異常信息可以看出：

1. 主分片當(dāng)前處于未分配狀態(tài)（current_state），發(fā)生這個(gè)問(wèn)題的原因是因?yàn)榉峙淞嗽摲制墓?jié)點(diǎn)已從集群中離開(kāi)(unassigned_info.reason)；
2. 發(fā)生了上訴問(wèn)題之后，分片無(wú)法自動(dòng)分配分片的原因是集群中沒(méi)有該分片的可用副本( can_allocate )；
3. 同時(shí)也給出了更詳細(xì)的信息（allocate_explanation）

這種情況發(fā)生的原因是因?yàn)榧河泄?jié)點(diǎn)下線，導(dǎo)致主分片已沒(méi)有任何可用的分片數(shù)據(jù)，當(dāng)前唯一能做的事就是等待節(jié)點(diǎn)恢復(fù)并重新加入集群。

注：某些極端場(chǎng)景，比如單副本集群的分片發(fā)生了損壞，或是文件系統(tǒng)故障導(dǎo)致該節(jié)點(diǎn)被永久移除，而此時(shí)只能接受數(shù)據(jù)丟失的事實(shí)，并通過(guò)reroute commends來(lái)重新分配空的主分片。

分片未分配（unassigned_info.reason）的所有可能

可以通過(guò)上訴分析方式初步判斷集群產(chǎn)生未分配分片的原因，一般都可以在allocation explain api中得到想要的答案。

異常狀態(tài)分析

我們已經(jīng)了解了 ES 集群異常狀態(tài)分為 YELLOW 和 RED。

YELLOW：主分片可用，但是副本分片不可用。這種情況 Elasticsearch 集群所有的主分片已經(jīng)分配了，但至少還有一個(gè)副本是未分配的。不會(huì)有數(shù)據(jù)丟失，所以搜索結(jié)果依然是完整的。不過(guò)，集群高可用性在某種程度上會(huì)被弱化。可以把 yellow 想象成一個(gè)需要關(guān)注的 warnning，該情況不影響索引讀寫(xiě)，一般會(huì)自動(dòng)恢復(fù)。

RED：存在不可用的主分片。此時(shí)執(zhí)行查詢雖然部分?jǐn)?shù)據(jù)仍然可以查到，但實(shí)際上已經(jīng)影響到索引讀寫(xiě)，需要重點(diǎn)關(guān)注。這種情況 Elasticsearch 集群至少一個(gè)主分片（以及它的全部副本）都在缺失中。這意味著索引已缺少數(shù)據(jù)，搜索只能返回部分?jǐn)?shù)據(jù)，而分配到這個(gè)分片上的請(qǐng)求都返回異常。

本文我們將講解集群在 YELLOW 異常狀態(tài)下的處理思路，以及哪些情況下無(wú)需人工干預(yù)，哪些情況下需要人工干預(yù)。

YELLOW 異常

yellow 異常是 ES 最常見(jiàn)的集群異常，當(dāng)負(fù)載較高時(shí)，集群往往會(huì)長(zhǎng)時(shí)間陷入 yellow 狀態(tài)無(wú)法脫離，其表現(xiàn)則是：

• 無(wú)需人工干預(yù)，副本分片恢復(fù)緩慢，大部分副本分片處于排隊(duì)等待初始化
• 需要人工干預(yù)，副本分片無(wú)法分配

無(wú)需人工干預(yù)

場(chǎng)景1：寫(xiě)入觸發(fā)索引創(chuàng)建（INDEX_CREATED）

ES 支持在索引不存在的情況下發(fā)起對(duì)該索引的寫(xiě)入，當(dāng)對(duì)不存在的索引發(fā)起寫(xiě)入時(shí)，ES 會(huì)自動(dòng)創(chuàng)建該索引，并開(kāi)始自動(dòng)映射（put-mapping）不存在的索引字段，這是個(gè)很重的操作，會(huì)對(duì)元數(shù)據(jù)造成較大壓力。

尤其當(dāng)有大量寫(xiě)入或者集群本身元數(shù)據(jù)較大時(shí)，ES 會(huì)延遲分配副本分片，進(jìn)入 pending_task 隊(duì)列，這則會(huì)導(dǎo)致集群陷入 yellow 狀態(tài)。這時(shí)即便副本分片開(kāi)始初始化，也會(huì)因?yàn)樗饕写罅繉?xiě)入而需要同步主分片數(shù)據(jù)，進(jìn)而導(dǎo)致副本初始化緩慢。

整體表現(xiàn)就是集群長(zhǎng)時(shí)間處于 yellow 狀態(tài)，短時(shí)間無(wú)法脫離，但這種情況都會(huì)自動(dòng)恢復(fù)，當(dāng)副本分片初始化完成后，yellow 狀態(tài)也就變?yōu)?green 了。

如圖：當(dāng) URGENT Task過(guò)多時(shí)，則會(huì)導(dǎo)致 HIGH Task 排隊(duì)，進(jìn)入 pending 狀態(tài)

優(yōu)化建議：

業(yè)務(wù)提前預(yù)創(chuàng)建索引，而不是讓 bulk request 自動(dòng)觸發(fā)索引創(chuàng)建（create-index）。

場(chǎng)景2：節(jié)點(diǎn)臨時(shí)離線（NODE_LEFT）

我們假設(shè)集群當(dāng)中所有索引都有冗余副本分片，且只有一個(gè)節(jié)點(diǎn)宕機(jī)下線，那么集群這時(shí)會(huì)進(jìn)入 yellow 狀態(tài)。由于索引目前還有主分片在線，對(duì)業(yè)務(wù)的使用不會(huì)造成影響。如果節(jié)點(diǎn)是因?yàn)槎虝r(shí)間壓力過(guò)大而導(dǎo)致節(jié)點(diǎn)脫離，則一般會(huì)自動(dòng)恢復(fù)，這種情況無(wú)需人工干預(yù)：

[o.e.c.r.a.AllocationService] [1699879628011021732] failing shard [failed shard, shard [.ds-cdwch-2023.11.13-000404][23], node[vAnpreEnTaSWY-QYV3GGWg], [R], recovery_source[peer recovery], s[INITIALIZING], a[id=r48vj2pQRmauAuXKm-qX9g], unassigned_info[[reason=NODE_LEFT], at[2023-11-14T06:58:10.583Z], delayed=true, details[node_left [vAnpreEnTaSWY-QYV3GGWg]], allocation_status[no_attempt]], message [failed recovery], failure [RecoveryFailedException[[.ds-cdwch-2023.11.13-000404][23]: Recovery failed from {1675171390003468332}{QUotMJ0DRsiM442JPtqlmA}{2aWADQvMRjSKRRsFg-Abrw}{10.1.0.47}{10.1.0.47:9300}{hilrst}{ml.machine_memory=67168968704, rack=cvm_8_800007, xpack.installed=true, set=800007, transform.node=true, ip=9.15.118.138, ml.max_open_jobs=512, ml.max_jvm_size=34326183936, region=8} into {1670988404000091932}{vAnpreEnTaSWY-QYV3GGWg}{-vaCwjbhSpG1iGEY18Wz4A}{10.0.128.45}{10.0.128.45:9300}{hilrst}{ml.machine_memory=67168968704, rack=cvm_8_800006, xpack.installed=true, set=800006, transform.node=true, ip=9.15.104.46, ml.max_open_jobs=512, ml.max_jvm_size=34326183936, region=8}]; nested: RemoteTransportException[[1675171390003468332][10.1.0.47:9300][internal:index/shard/recovery/start_recovery]]; nested: ScpRecoveryIsRunningException[Another recovery task is running for same replica and node. Existing recovery: RecoveryKey{shard: [.ds-cdwch-2023.11.13-000404][23], target:vAnpreEnTaSWY-QYV3GGWg, recovery:101021}, New recovery: RecoveryKey{shard: [.ds-cdwch-2023.11.13-000404][23], target:vAnpreEnTaSWY-QYV3GGWg, recovery:101026}]; ], markAsStale [true]]
org.elasticsearch.indices.recovery.RecoveryFailedException: [.ds-cdwch-yuogefjn-es-let66hx8-space-mk4wn5x5-2023.11.13-000404][23]: Recovery failed from {1675171390003468332}{QUotMJ0DRsiM442JPtqlmA}{2aWADQvMRjSKRRsFg-Abrw}{10.1.0.47}{10.1.0.47:9300}{hilrst}{ml.machine_memory=67168968704, rack=cvm_8_800007, xpack.installed=true, set=800007, transform.node=true, ip=9.15.118.138, ml.max_open_jobs=512, ml.max_jvm_size=34326183936, region=8} into {1670988404000091932}{vAnpreEnTaSWY-QYV3GGWg}{-vaCwjbhSpG1iGEY18Wz4A}{10.0.128.45}{10.0.128.45:9300}{hilrst}{ml.machine_memory=67168968704, rack=cvm_8_800006, xpack.installed=true, set=800006, transform.node=true, ip=9.15.104.46, ml.max_open_jobs=512, ml.max_jvm_size=34326183936, region=8}
	at org.elasticsearch.indices.recovery.PeerRecoveryTargetService$RecoveryResponseHandler.handleException(PeerRecoveryTargetService.java:786) ~[elasticsearch-7.14.2.jar:7.14.2]
	at org.elasticsearch.transport.TransportService$ContextRestoreResponseHandler.handleException(TransportService.java:1324) ~[elasticsearch-7.14.2.jar:7.14.2]
	at org.elasticsearch.transport.TransportService$ContextRestoreResponseHandler.handleException(TransportService.java:1324) ~[elasticsearch-7.14.2.jar:7.14.2]
	at org.elasticsearch.transport.InboundHandler.lambda$handleException$3(InboundHandler.java:335) ~[elasticsearch-7.14.2.jar:7.14.2]
	at org.elasticsearch.common.util.concurrent.ThreadContext$ContextPreservingRunnable.run(ThreadContext.java:673) ~[elasticsearch-7.14.2.jar:7.14.2]
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) [?:?]
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) [?:?]
	at java.lang.Thread.run(Thread.java:834) [?:?]
Caused by: org.elasticsearch.transport.RemoteTransportException: [1675171390003468332][10.1.0.47:9300][internal:index/shard/recovery/start_recovery]

優(yōu)化建議：

節(jié)點(diǎn)一般不會(huì)無(wú)故離線，如果發(fā)生節(jié)點(diǎn)偶現(xiàn)脫離，則要進(jìn)一步排查 ES 是否存在資源瓶頸。

場(chǎng)景3：集群發(fā)生熔斷（ALLOCATION_FAILED）

什么是熔斷

Elasticsearch Service 提供了多種官方的熔斷器（circuit breaker），用于防止內(nèi)存使用過(guò)高導(dǎo)致 ES 集群因?yàn)?OutOfMemoryError 而出現(xiàn)問(wèn)題。Elasticsearch 設(shè)置有各種類型的子熔斷器，負(fù)責(zé)特定請(qǐng)求處理的內(nèi)存限制。此外，還有一個(gè)父熔斷器，用于限制所有子熔斷器上使用的內(nèi)存總量。

熔斷器介紹

父熔斷器（Parent circuit breaker） 父熔斷器限制所有子熔斷器上使用的內(nèi)存總量，當(dāng)觸發(fā)父熔斷器熔斷時(shí)，可能的日志信息如下：

Caused by: org.elasticsearch.common.breaker.CircuitBreakingException: [parent] Data too large, data for [<transport_request>] would be [1749436147/1.6gb], which is larger than the limit of [1622605824/1.5gb], real usage: [1749435872/1.6gb], new bytes reserved: [275/275b]

Field data 熔斷器（Field data breaker） 當(dāng)對(duì) text 字段聚合或排序時(shí)，會(huì)產(chǎn)生 Field data 數(shù)據(jù)結(jié)構(gòu)。Field data 熔斷器會(huì)預(yù)估有多少數(shù)據(jù)被加載到內(nèi)存中。當(dāng)預(yù)估的數(shù)據(jù)占用內(nèi)存到達(dá) Field data 熔斷器閾值時(shí)，會(huì)觸發(fā) Field data 熔斷器熔斷。此時(shí)可能的日志信息如下：

org.elasticsearch.common.breaker.CircuitBreakingException: [fielddata] Data too large, data for [_id] would be [943928680/900.2mb], which is larger than the limit of [255606128/243.7mb]

In flight 請(qǐng)求熔斷器（In flight requests circuit breaker） In flight 請(qǐng)求熔斷器限制了在 transport 和 HTTP 層的所有當(dāng)前傳入的請(qǐng)求所使用的內(nèi)存。當(dāng)觸發(fā) In flight 請(qǐng)求熔斷器時(shí)，可能的日志信息如下：

[o.e.x.m.e.l.LocalExporter] [1611816935001404932] unexpected error while indexing monitoring documentorg.elasticsearch.xpack.monitoring.exporter.ExportException: RemoteTransportException[[1611816935001404732][9.10.153.16:9300][indices:data/write/bulk[s]]]; nested: CircuitBreakingException[[in_flight_requests] Data too large, data for [<transport_request>] would be [19491363612/18.1gb], which is larger than the limit of [17066491904/15.8gb]];

優(yōu)化建議：

出現(xiàn)熔斷說(shuō)明當(dāng)前節(jié)點(diǎn) JVM 使用率過(guò)高，通過(guò)熔斷保護(hù)進(jìn)程不會(huì) OOM。可以通過(guò)適當(dāng)降低讀寫(xiě)、清理內(nèi)存等方法降低節(jié)點(diǎn)負(fù)載，也可以通過(guò)升級(jí)節(jié)點(diǎn)內(nèi)存規(guī)格來(lái)提高 JVM 大小。

場(chǎng)景4：增加副本分片（ REPLICA_ADDED）

ES 副本可以給業(yè)務(wù)帶來(lái)查詢性能吞吐的提升，同時(shí)可以增加數(shù)據(jù)的高可用。每增加1個(gè)副本，索引數(shù)據(jù)可承受節(jié)點(diǎn)離線數(shù)量也就加1，這也就意味著副本分片對(duì)于 ES 來(lái)說(shuō)是多么重要。

然而我們?cè)?add replicas 的時(shí)候，集群會(huì)立即進(jìn)入 YELLOW 狀態(tài)，這是因?yàn)?ES 集群狀態(tài)的判定是分片級(jí)別。也就是說(shuō)但凡有一塊分片不是 ready 狀態(tài)，都會(huì)影響 cluster health。這時(shí)我們只需耐心等待即可，待副本分片初始化完成，集群就會(huì)恢復(fù) GREEN 狀態(tài)。

建議：

add replicas 有一定性能開(kāi)銷(xiāo)，建議在業(yè)務(wù)低峰期進(jìn)行。

場(chǎng)景5：進(jìn)行快照恢復(fù)（NEW_INDEX_RESTORED）

快照恢復(fù)是個(gè)例外，我們知道，ES 集群狀態(tài)的判定是分片級(jí)別。也就是說(shuō)但凡有一塊分片不是 ready 狀態(tài)，都會(huì)影響 cluster health，那么 ES 在發(fā)起快照恢復(fù)時(shí)，主分片一定不是 ready 狀態(tài)，但這個(gè)不會(huì)造成集群 RED，只會(huì)導(dǎo)致集群發(fā)生 YELLOW，直到快照數(shù)據(jù)恢復(fù)完成。

建議：

快照操作有一定性能開(kāi)銷(xiāo)，建議在業(yè)務(wù)低峰期進(jìn)行。

需要人工干預(yù)

場(chǎng)景1：磁盤(pán)水位問(wèn)題（ALLOCATION_FAILED）

磁盤(pán)水位過(guò)高會(huì)導(dǎo)致 ES 新生分片無(wú)法分配，更嚴(yán)重甚至?xí)?dǎo)致節(jié)點(diǎn)離線。

• 集群所有節(jié)點(diǎn)都達(dá)到磁盤(pán)低水位，導(dǎo)致副本分片不允許分配
• 磁盤(pán)寫(xiě)滿而導(dǎo)致節(jié)點(diǎn)永久脫離

這兩種情況都會(huì)導(dǎo)致集群 YELLOW，不同的是，如果只是個(gè)別節(jié)點(diǎn)磁盤(pán)寫(xiě)滿導(dǎo)致節(jié)點(diǎn)離線，達(dá)到閾值之后，會(huì)強(qiáng)制分配副本到其他節(jié)點(diǎn)（unassigned.node_left.delayed_timeout），但如果所有節(jié)點(diǎn)都達(dá)到磁盤(pán)低水位，那么副本分片將無(wú)法再分配，直到人為干預(yù)：

[o.e.c.r.a.DiskThresholdMonitor] [1655733980000740332] low disk watermark [85%] exceeded on [4s2ulawjTSSvt-QQlqsDPQ][1655800410000987332][/data1/containers/1655800410000987332/es/data/nodes/0] free: 70.1gb[14.2%], replicas will not be assigned to this node

優(yōu)化建議：

• 訂閱集群告警，及時(shí)發(fā)現(xiàn)集群水位，保持集群磁盤(pán)水位在健康狀態(tài)。
• 制定 ILM（索引生命周期管理）策略，定期清理過(guò)期數(shù)據(jù)，保持健康水位。

場(chǎng)景2：節(jié)點(diǎn)永久離線（NODE_LEFT）

我們同樣假設(shè)集群當(dāng)中所有索引都有冗余副本分片，且只有一個(gè)節(jié)點(diǎn)宕機(jī)下線，只不過(guò)因?yàn)橐恍┰颍@個(gè)節(jié)點(diǎn)不會(huì)再加回集群，那么集群這時(shí)會(huì)進(jìn)入 yellow 狀態(tài)。如果不人為干預(yù)，則會(huì)在 delayed_timeout 達(dá)到閾值后強(qiáng)制分配到其他節(jié)點(diǎn)，當(dāng)然，這也就會(huì)降低 ES 的整體性能：

[o.e.c.r.a.AllocationService] [1699879628011021732] failing shard [failed shard, shard [.ds-cdwch-2023.11.13-000404][23], node[vAnpreEnTaSWY-QYV3GGWg], [R], recovery_source[peer recovery], s[INITIALIZING], a[id=r48vj2pQRmauAuXKm-qX9g], unassigned_info[[reason=NODE_LEFT], at[2023-11-14T06:58:10.583Z], delayed=true, details[node_left [vAnpreEnTaSWY-QYV3GGWg]], allocation_status[no_attempt]], message [failed recovery], failure [RecoveryFailedException[[.ds-cdwch-2023.11.13-000404][23]: Recovery failed from {1675171390003468332}{QUotMJ0DRsiM442JPtqlmA}{2aWADQvMRjSKRRsFg-Abrw}{10.1.0.47}{10.1.0.47:9300}{hilrst}{ml.machine_memory=67168968704, rack=cvm_8_800007, xpack.installed=true, set=800007, transform.node=true, ip=9.15.118.138, ml.max_open_jobs=512, ml.max_jvm_size=34326183936, region=8} into {1670988404000091932}{vAnpreEnTaSWY-QYV3GGWg}{-vaCwjbhSpG1iGEY18Wz4A}{10.0.128.45}{10.0.128.45:9300}{hilrst}{ml.machine_memory=67168968704, rack=cvm_8_800006, xpack.installed=true, set=800006, transform.node=true, ip=9.15.104.46, ml.max_open_jobs=512, ml.max_jvm_size=34326183936, region=8}]; nested: RemoteTransportException[[1675171390003468332][10.1.0.47:9300][internal:index/shard/recovery/start_recovery]]; nested: ScpRecoveryIsRunningException[Another recovery task is running for same replica and node. Existing recovery: RecoveryKey{shard: [.ds-cdwch-2023.11.13-000404][23], target:vAnpreEnTaSWY-QYV3GGWg, recovery:101021}, New recovery: RecoveryKey{shard: [.ds-cdwch-2023.11.13-000404][23], target:vAnpreEnTaSWY-QYV3GGWg, recovery:101026}]; ], markAsStale [true]]

優(yōu)化建議：

節(jié)點(diǎn)一般不會(huì)無(wú)故離線，如果發(fā)生節(jié)點(diǎn)偶現(xiàn)脫離，則要進(jìn)一步排查 ES 是否存在資源瓶頸。

場(chǎng)景3：副本分片過(guò)多（ALLOCATION_FAILED）

對(duì)于 ES 相同一個(gè)節(jié)點(diǎn)，無(wú)法分配同一塊副本分片，這也就意味著，索引的最大副本數(shù)（Replicas） = Date Node 數(shù)量 - 1，當(dāng) Replicas >= Date Node nums 時(shí)，則會(huì)發(fā)生副本無(wú)法繼續(xù)分配的情況，要避免此問(wèn)題，請(qǐng)按照以下公式，確保每個(gè)索引的每個(gè)副本分片少于群集中節(jié)點(diǎn)的數(shù)量：

N >= R + 1

其中 N 是 ES 集群中節(jié)點(diǎn)的數(shù)量，R 是索引的副本數(shù)量（num_of_replicas）。

總結(jié)

YELLOW 狀態(tài)可能會(huì)降低集群讀寫(xiě)性能，當(dāng)然，除此之外，YELLOW 對(duì)業(yè)務(wù)無(wú)其他負(fù)面影響，但是有一點(diǎn)格外重要 —— task schedule。

我們知道，ES 的 task 調(diào)度有優(yōu)先級(jí)，其中 allocation replicas shards 的優(yōu)先級(jí)就比 relocation 要高，也就是說(shuō)，當(dāng)集群處于 yellow 狀態(tài)時(shí)，ES 默認(rèn)是不會(huì)觸發(fā) rebalance 的，這一點(diǎn)很可怕。

正因?yàn)?ES 有 shards rebalance 的機(jī)制，才能做到盡可能的負(fù)載均衡，以充分發(fā)揮分布式計(jì)算的性能。試想一下，當(dāng) rebalance 無(wú)法觸發(fā)時(shí)，ES 將會(huì)是什么狀態(tài)？我想大家很容易想到的就是：熱點(diǎn)瓶頸、負(fù)載不均，甚至讀寫(xiě)拒絕。好在是 ES 在設(shè)計(jì)之初想到了這點(diǎn)，所以提供了一個(gè)動(dòng)態(tài)參數(shù)以供調(diào)整：

PUT _cluster/settings
{
  "transient": {
    "cluster.routing.allocation.allow_rebalance": "indices_primaries_active"
  }
}

• always - 任何情況都可觸發(fā) rebalance，包括集群 RED
• indices_primaries_active - 主分片 Ready 即可觸發(fā) rebalance，包括集群 YELLOW
• indices_all_active - （默認(rèn)）所有分片都 Ready 才能觸發(fā) rebalance，也就是集群 GREEN