Elasticsearch:_split API を使用してインデックスをプライマリシャード数の多い新しいインデックスに分割する

前提条件

• Elasticsearch クラスタは正常であり、クラスタの負荷は正常です。
• インデックスの分割後に取得できるプライマリシャードの数は、Elasticsearch クラスタ内のデータノードの数とディスク容量に基づいて評価されます。詳細については、「シャードの評価」をご参照ください。
• インデックスのデータ書き込み操作は無効になっています。Elasticsearch クラスタには、新しいインデックスと同じ名前のインデックスは含まれていません。
• Elasticsearch クラスタには、新しいインデックスを格納するための十分なディスク容量があります。

手順

1. Elasticsearch クラスタの Kibana コンソールにログインし、プロンプトに従って Kibana コンソールのホームページに移動します。

   Kibana コンソールへのログイン方法の詳細については、「Kibana コンソールへのログイン」をご参照ください。

   説明

   この例では、Elasticsearch V7.10.0 クラスタを使用しています。他のバージョンのクラスタでの操作は異なる場合があります。コンソールでの実際の操作が優先されます。

2. 表示されるページの右上隅にある [dev Tools] をクリックします。

3. 表示されるページの [Console] タブで、次のコマンドを実行してインデックスを作成します。コマンドでは、index.number_of_routing_shards パラメータを構成してルーティングシャードの数を指定し、index.number_of_shards パラメータを構成してプライマリシャードの数を指定します。
   インデックスの分割後に取得できるプライマリシャードの数は、index.number_of_routing_shards パラメータの値の因数であり、index.number_of_shards パラメータの値の倍数です。この例では、dest1 という名前のインデックスが Elasticsearch V7.10 クラスタに作成されます。index.number_of_routing_shards パラメータは 24 に設定され、index.number_of_shards パラメータは 2 に設定されます。この場合、インデックスの分割後に取得できるプライマリシャードの数は、4、6、8、12、または 24 です。

   説明 ビジネス要件に基づいて、次のコマンドの dest1 を置き換える必要があります。

   PUT /dest1
   {
     "settings": {
       "index": {
         "number_of_routing_shards": 24, // ルーティングシャードの数を設定します
         "number_of_shards":2 // プライマリシャードの数を設定します
       }
     }
   }

   パラメータ	説明
   number_of_routing_shards	ルーティングシャードの数。このパラメータは、元のインデックスを分割できる回数、または分割後に取得できるプライマリシャードの数を定義します。インデックスを作成するときは、インデックスに構成されているプライマリシャードの数がこのパラメータの値の因数であることを確認する必要があります。 説明 V7.0 より前のバージョンの Elasticsearch クラスタでインデックスを分割する場合は、インデックスの作成に使用されるコマンドで index.number_of_routing_shards パラメータを構成する必要があり、このパラメータの最大値は 1024 です。デフォルトでは、V7.0 以降の Elasticsearch クラスタの場合、index.number_of_routing_shards パラメータの値は、クラスタ内で分割するインデックスのプライマリシャードの数に関連しています。V7.0 以降の Elasticsearch クラスタでインデックスを分割する場合、このパラメータがインデックスの作成に使用されるコマンドで構成されていない場合、インデックスはデフォルトで 2 の因数で分割され、分割後に最大 1,024 のプライマリシャードを取得できます。たとえば、元のインデックスのプライマリシャードの数が 1 の場合、分割後に取得されるプライマリシャードの数は 1 から 1,024 までの数になります。元のインデックスのプライマリシャードの数が 5 の場合、分割後に取得できるプライマリシャードの数は 10、20、40、80、160、320、または 640 です。分割後に取得できるプライマリシャードの最大数は 640 です。 _shrink API を使用してプライマリシャードが縮小されたインデックスを分割する場合は、分割後に取得されるプライマリシャードの数が分割前のプライマリシャードの数の倍数であることを確認する必要があります。たとえば、分割前のプライマリシャードの数が 5 の場合、分割後に取得されるプライマリシャードの数は 5 の倍数（10、15、20、25、30 など）である必要があります。分割後に取得されるプライマリシャードの数は 1,024 を超えることはできません。
   number_of_shards	インデックスのプライマリシャードの数。

4. データを挿入します。
   説明 次のデータはテスト用にのみ使用されます。

   POST /dest1/_doc/_bulk
   {"index":{}}
   {"productName":"Product A","annual_rate":"3.2200%","describe":"A product that allows you to select whether to receive push messages for returns."} // 収益のプッシュメッセージを受信するかどうかを選択できる商品。
   {"index":{}}
   {"productName":"Product B","annual_rate":"3.1100%","describe":"A product that daily pushes messages for returns credited to your account."} // アカウントに入金された収益のメッセージを毎日プッシュする商品。
   {"index":{}}
   {"productName":"Product C","annual_rate":"3.3500%","describe":"A product that daily pushes messages for returns immediately credited to your account."} // アカウントに即時入金された収益のメッセージを毎日プッシュする商品。
   

5. インデックスのデータ書き込み操作を無効にします。

   PUT /dest1/_settings
   {
     "settings": {
       "index.blocks.write": true // データの書き込みを無効にします
     }
   }

6. 元のインデックスをプライマリシャード数の多い新しいインデックスに分割し、新しいインデックスのデータ書き込み操作を有効にします。

   POST dest1/_split/dest3
   {
     "settings": {
       "index.number_of_shards": 12, // 新しいインデックスのプライマリシャードの数を設定します
       "index.blocks.write": null // データの書き込みを有効にします
     }
   }

   この例では、宛先 1宛先 3_split API を使用して、元のインデックス

   重要

   • 元のインデックスのプライマリシャードの数は 2 で、index.number_of_routing_shards パラメーターは 24 に設定されています。この場合、新しいインデックスのプライマリシャードの数は 2 の倍数でなければならず、24 を超えることはできません。そうでない場合、Kibana コンソールでエラーが報告されます。
   • 分割中、システムはノード上のセグメントをマージします。この操作は、Elasticsearch クラスターのコンピューティングリソースを消費し、クラスターの負荷を増加させます。そのため、インデックスを分割する前に、Elasticsearch クラスターに十分なディスク容量があることを確認する必要があります。オフピーク時にインデックスを分割することをお勧めします。
   • 上記の各コマンドの dest1 と dest3 は、ビジネス要件に基づいて置き換える必要があります。

   が新しいインデックス に分割されます。新しいインデックスのプライマリシャードの数は 12 で、新しいインデックスのデータ書き込み操作は有効になっています。
7. 結果を表示します。
   _cat recovery API を呼び出して、インデックスの分割の進捗状況をクエリします。シャード分割に関するリカバリが返されず、Elasticsearch クラスタが正常な場合、インデックスの分割は完了です。

   • インデックスの分割の進捗状況をクエリする

     GET _cat/recovery?v&active_only

     返された結果の index 列に分割待ちのインデックスが表示されない場合、インデックス分割に関するリカバリは存在しません。

   • Elasticsearch クラスタのヘルスステータスをクエリする

     GET _cluster/health

     返された結果に "status" : "green" が含まれている場合、Elasticsearch クラスタは正常です。

FAQ

Q: インデックス分割操作の完了後、Elasticsearch クラスタ内の各データノードの CPU 使用率と分平均負荷が低下しないのはなぜですか？

A: インデックスを分割すると、システムはインデックス内のドキュメントを再ルーティングし、新しいインデックスには多数の docs.deleted ドキュメントが含まれます。GET _nodes/hot_threads コマンドを実行すると、元のインデックスでマージ操作が実行されていることを確認できます。マージ操作は Elasticsearch クラスタの多くの計算リソースを消費します。オフピーク時にインデックスを分割することをお勧めします。