如何通過_shrinkAPI快速減少主分區數 - Elasticsearch

在Elasticsearch叢集中建立索引時，如果您無法評估實際資料量，可能導致設定的主分數很大，但實際業務的資料量並不多，此時您需要減少主分區數，防止因主分區數太多導致叢集資源消耗過大或影響查詢寫入速率等。本文為您介紹如何通過_shrink API快速減少主分區數。

背景資訊

使用Elasticsearch需要密切關注叢集分區總數及索引分區數設定。叢集分區總數越多，對應分區會佔用大量的檔案控制代碼耗用大量的叢集資源。同樣，索引分區數設定不合理，會對查詢和寫入均造成潛在的影響。

在建立索引時，如果您無法評估實際資料量，可能導致設定的索引主分數很大，但實際業務資料量並不多。通過reindex減少主分區數耗時太久，elastic提供了_shrink API可快速減少索引主分區數。shrink操作不會在原索引上直接縮小分區，基本流程如下：

建立一個和原索引配置相同的新索引，新索引主分區比原索引少，所有分區需彙集在一個節點，該節點預留的磁碟空間需要大於原索引主分區上的資料大小。
從原索引到新索引建立segments永久連結。
對新索引執行恢複操作，類似關閉的索引執行開啟操作。

reindex與_shrink API的效能測試資訊如下：

測試環境：
- 資料節點：數量為5個，規格為8核16 GB。
- 索引資料：資料量為182 GB。
- 分區數：原主分區數為30，目標分區數為5，副本數為0。
測試結果
方式
耗時
資源佔用
reindex
3小時22分鐘
叢集中有大量的寫QPS，索引所佔節點資源高。
_shrink API
15分鐘
shrink節點計算資源較高。

前提條件

Elasticsearch叢集狀態健康，且負載處於正常水位。
根據叢集資料節點個數、叢集磁碟容量等因素，合理評估索引可減少的分區數。詳細資料請參見評估Shard。
原索引必須處於green狀態。
原索引的文檔總數不能超過2,147,483,519。
Elasticsearch叢集中沒有新索引的同名索引。

操作步驟

登入目標Elasticsearch執行個體的Kibana控制台，根據頁面提示進入Kibana首頁。
登入Kibana控制台的具體操作，請參見登入Kibana控制台。
說明本文以Elasticsearch 7.10.0版本為例，其他版本操作可能略有差別，請以實際介面為準。
單擊右上方的Dev tools。

在Console中，執行如下命令，將原索引設定為禁止寫狀態，副本置為0，且將分區彙集到叢集中的一個節點上。

以下樣本以原索引shrink5為例，使用時需要替換為您的業務索引名。

PUT shrink5/_settings
{
    "index.routing.allocation.require._name": "es-cn-zvp25yhyy000y****-1ab7****-0001",
    "index.blocks.write": true,
    "index.number_of_replicas": 0
}

參數	說明
index.routing.allocation.require._name	設定分區彙集的目標節點name。節點name可通過`GET _cat/nodes?v`命令擷取。說明在通過`_shrink` API減少主分區數之前，原索引的每個分區必須彙集到叢集中的一個節點上。
index.blocks.write	是否禁用對索引的寫操作，必須為true，即禁止寫操作。說明在通過`_shrink` API減少主分區數之前，必須設定原索引為禁止寫狀態。
index.number_of_replicas	索引的副本分區數。

通過_shrink API減少主分區數。

以下樣本以將原索引shrink5的主分區數從30減少到5，並產生新索引shrink_hk5e_cn。使用時請替換索引名。

POST shrink5/_shrink/shrink_hk5e_cn
{
  "settings": {
    "index.blocks.write": null,
    "index.number_of_shards": 5,
    "index.number_of_replicas": 0,
    "index.routing.allocation.require._name": null
  }
}

參數	說明
index.blocks.write	是否禁用對索引的寫操作。在通過`_shrink` API減少主分區數後，需要將新索引的index.blocks.write置為null，即清除從原索引複製的配置。
index.number_of_shards	新索引的主分區數。重要觸發shrink後，shrink_node節點CPU使用率和load_1m將比較高，建議在業務低峰期操作。原索引的主分區數一定要大於新索引，新索引的主分區數必須可被原索引的主分區數整除。例如，原索引的主分區數為8，則可以減少到4、2、1；原索引的主分區數為15，則可以減少到5、3、1。如果原索引的主分區數是質數，則只能減少到1。
index.number_of_replicas	新索引的副本分區數。
index.routing.allocation.require._name	設定將分區彙集的目標節點。在通過`_shrink` API減少主分區數後，需要將新索引的index.routing.allocation.require._name置為null清除從原索引複製的配置，或者刪除原索引。

查看結果。
通過_cat recovery API查看shrink進度，當無shrink相關的recovey，且叢集狀態健康，則shrink完成。
- 查看shrink進度
```
GET _cat/recovery?v&active_only
```
  當返回結果的index列沒有等待shrink的索引時，說明無shrink相關的recovey。
- 查看叢集健康狀態
```
GET _cluster/health
```
  當返回結果中包含"status" : "green"時，說明叢集狀態健康。

常見問題

Q：為什麼要使用永久連結，而不使用軟連結？

A：通過軟連結建立索引，待資料寫入，將原索引刪除後，目標索引資料也會被刪除，而永久連結會保證索引的獨立性。

方式	耗時	資源佔用
reindex	3小時22分鐘	叢集中有大量的寫QPS，索引所佔節點資源高。
`_shrink` API	15分鐘	shrink節點計算資源較高。