Elasticsearch:_shrink API を使用してインデックスをより少ないプライマリシャードを持つ新しいインデックスに縮小

前提条件

• ご利用の Elasticsearch クラスターが正常であり、通常の負荷状態であること。

• クラスター内のデータノードの数と利用可能なディスク容量に基づいて、削除するプライマリシャードの数を評価します。詳細については、「シャードの評価」をご参照ください。

• 元のインデックスのステータスが green であること。

• 元のインデックスに含まれるドキュメントが 2,147,483,519 件以下であること。

• ご利用の Elasticsearch クラスターに、新しいインデックスと同じ名前のインデックスが存在しないこと。

操作手順

1. ご利用の Elasticsearch クラスターの Kibana コンソールにログインし、Kibana のホームページに移動します。

2. 左側のナビゲーションメニューで、[開発ツール] をクリックします。

3. [コンソール] で、次のコマンドを実行して、元のインデックスへの書き込みを無効にし、レプリカシャードの数を 0 に設定し、すべてのシャードをクラスター内の 1 つのノードに再配置します。

   この例では、元のインデックスとして 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	シャードを再配置するノードの 名前。ノード 名は GET _cat/nodes?v を実行して取得します。 説明 _shrink API を呼び出す前に、元のインデックスのすべてのシャードをクラスター内の 1 つのノードに再配置する必要があります。
   index.blocks.write	インデックスへの書き込みを無効にします。このパラメーターを true に設定します。 説明 _shrink API を呼び出す前に、元のインデックスへの書き込みを無効にする必要があります。
   index.number_of_replicas	インデックスのレプリカシャードの数。

4. _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 ノードの CPU 使用率と 1 分間の負荷が増加します。shrink はオフピーク時間に実行してください。 元のインデックスは、新しいインデックスよりも多くのプライマリシャードを持つ必要があります。元のインデックスのプライマリシャード数は、新しいインデックスのプライマリシャード数で割り切れる必要があります。たとえば、元のインデックスに 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 に設定して、元のインデックスからコピーされた構成をクリアするか、元のインデックスを削除します。

5. 結果の表示

   _cat recovery API を呼び出して、shrink の進捗を確認します。shrink に関連する回復が残っておらず、クラスターが正常な状態になると、shrink は完了です。

   • shrink の進捗確認

     GET _cat/recovery?v&active_only

     応答の index 列に shrink を待機しているインデックスが表示されなくなった場合、shrink に関連する回復は残っていません。

   • クラスターのヘルス状態の確認

     GET _cluster/health

     応答に "status" : "green" が含まれている場合、クラスターは正常です。

よくある質問

Q：なぜシンボリックリンクではなくハードリンクを使用するのですか？

A：ハードリンクはインデックスの独立性を保証するためです。シンボリックリンクを使用した場合、新しいインデックスにデータを書き込んだ後に元のインデックスを削除すると、新しいインデックスのデータも削除されてしまいます。ハードリンクはこれを防ぎます。