シュリンク

許可されるフェーズ: ホット、ウォーム。

ソースインデックスの書き込みをブロックし、新しいインデックスにプライマリシャードを少なくしてシュリンクします。結果として得られるインデックスの名前は shrink-<random-uuid>-<original-index-name> です。このアクションは シュリンクAPI に対応しています。

shrink アクションの後、ソースインデックスを指していたエイリアスは新しいシュリンクされたインデックスを指します。ILMがデータストリームのバックインデックスに対して shrink アクションを実行すると、シュリンクされたインデックスはストリーム内のソースインデックスに置き換わります。書き込みインデックスに対して shrink アクションを実行することはできません。

shrink アクションを hot フェーズで使用するには、rollover アクション が 必要です。ロールオーバーアクションが設定されていない場合、ILMはポリシーを拒否します。

シュリンクアクションはインデックスの index.routing.allocation.total_shards_per_node 設定を解除し、制限がなくなることを意味します。これは、インデックスのすべてのシャードが単一のノードにコピーできるようにするためです。この設定変更は、ステップが完了した後もインデックスに持続します。

シュリンクアクションが フォロワーインデックス に使用される場合、ポリシーの実行はリーダーインデックスがロールオーバーするまで待機します（または 他の方法で完了としてマークされる）、その後、フォロワーインデックスを フォロー解除 アクションで通常のインデックスに変換してからシュリンク操作を実行します。

シュリンクオプション

  • number_of_shards
  • (オプション、整数) シュリンクするシャードの数。ソースインデックスのシャード数の因数でなければなりません。このパラメータは max_primary_shard_size と競合し、どちらか一方のみが設定できます。
  • max_primary_shard_size
  • (オプション、バイト単位) ターゲットインデックスの最大プライマリシャードサイズ。ターゲットインデックスの最適なシャード数を見つけるために使用されます。このパラメータが設定されると、ターゲットインデックス内の各シャードのストレージはこのパラメータを超えません。ターゲットインデックスのシャード数はソースインデックスのシャード数の因数であり続けますが、このパラメータがソースインデックスの単一シャードサイズより小さい場合、ターゲットインデックスのシャード数はソースインデックスのシャード数と等しくなります。たとえば、このパラメータが50GBに設定されている場合、ソースインデックスが合計100GBの60プライマリシャードを持っていると、ターゲットインデックスは2プライマリシャードを持ち、各シャードサイズは50GBになります。ソースインデックスが合計1000GBの60プライマリシャードを持っている場合、ターゲットインデックスは20プライマリシャードを持ちます。ソースインデックスが合計4000GBの60プライマリシャードを持っている場合、ターゲットインデックスは依然として60プライマリシャードを持ちます。このパラメータは number_of_shards と settings で競合し、どちらか一方のみが設定できます。
  • allow_write_after_shrink
  • (オプション、ブール値) trueの場合、シュリンクされたインデックスは 書き込みブロック を削除することによって書き込み可能になります。デフォルトはfalseです。

例

新しいシュリンクインデックスのシャード数を明示的に設定する

Python

  1. resp = client.ilm.put_lifecycle(
  2.    name="my_policy",
  3.    policy={
  4.    "phases": {
  5.    "warm": {
  6.    "actions": {
  7.    "shrink": {
  8.    "number_of_shards": 1
  9.    }
  10.    }
  11.    }
  12.    }
  13.    },
  14. )
  15. print(resp)

Ruby

  1. response = client.ilm.put_lifecycle(
  2.   policy: 'my_policy',
  3.   body: {
  4.    policy: {
  5.    phases: {
  6.    warm: {
  7.    actions: {
  8.    shrink: {
  9.    number_of_shards: 1
  10.    }
  11.    }
  12.    }
  13.    }
  14.    }
  15.   }
  16. )
  17. puts response

Js

  1. const response = await client.ilm.putLifecycle({
  2.   name: "my_policy",
  3.   policy: {
  4.    phases: {
  5.    warm: {
  6.    actions: {
  7.    shrink: {
  8.    number_of_shards: 1,
  9.    },
  10.    },
  11.    },
  12.    },
  13.   },
  14. });
  15. console.log(response);

コンソール

  1. PUT _ilm/policy/my_policy
  2. {
  3.   "policy": {
  4.    "phases": {
  5.    "warm": {
  6.    "actions": {
  7.    "shrink" : {
  8.    "number_of_shards": 1
  9.    }
  10.    }
  11.    }
  12.    }
  13.   }
  14. }

シュリンクインデックスの最適なプライマリシャード数を計算する

以下のポリシーは、max_primary_shard_size パラメータを使用して、ソースインデックスのストレージサイズに基づいて新しいシュリンクインデックスのプライマリシャード数を自動的に計算します。

Python

  1. resp = client.ilm.put_lifecycle(
  2.    name="my_policy",
  3.    policy={
  4.    "phases": {
  5.    "warm": {
  6.    "actions": {
  7.    "shrink": {
  8.    "max_primary_shard_size": "50gb"
  9.    }
  10.    }
  11.    }
  12.    }
  13.    },
  14. )
  15. print(resp)

Ruby

  1. response = client.ilm.put_lifecycle(
  2.   policy: 'my_policy',
  3.   body: {
  4.    policy: {
  5.    phases: {
  6.    warm: {
  7.    actions: {
  8.    shrink: {
  9.    max_primary_shard_size: '50gb'
  10.    }
  11.    }
  12.    }
  13.    }
  14.    }
  15.   }
  16. )
  17. puts response

Js

  1. const response = await client.ilm.putLifecycle({
  2.   name: "my_policy",
  3.   policy: {
  4.    phases: {
  5.    warm: {
  6.    actions: {
  7.    shrink: {
  8.    max_primary_shard_size: "50gb",
  9.    },
  10.    },
  11.    },
  12.    },
  13.   },
  14. });
  15. console.log(response);

コンソール

  1. PUT _ilm/policy/my_policy
  2. {
  3.   "policy": {
  4.    "phases": {
  5.    "warm": {
  6.    "actions": {
  7.    "shrink" : {
  8.    "max_primary_shard_size": "50gb"
  9.    }
  10.    }
  11.    }
  12.    }
  13.   }
  14. }

シュリンクのためのシャード割り当て

シュリンクアクション中、ILMはソースインデックスのプライマリシャードを1つのノードに割り当てます。インデックスをシュリンクした後、ILMはシュリンクされたインデックスのシャードを、あなたの割り当てルールに基づいて適切なノードに再割り当てします。

これらの割り当てステップは、いくつかの理由で失敗する可能性があります。

  • shrink アクション中にノードが削除される。
  • ソースインデックスのシャードをホストするのに十分なディスクスペースを持つノードがない。
  • Elasticsearchが競合する割り当てルールのためにシュリンクされたインデックスを再割り当てできない。

割り当てステップの1つが失敗した場合、ILMは index.lifecycle.step.wait_time_threshold に設定された期間、デフォルトは12時間待機します。この閾値期間は、クラスターが割り当て失敗の原因となる問題を解決するのを許可します。

閾値期間が経過し、ILMがまだインデックスをシュリンクしていない場合、ILMはソースインデックスのプライマリシャードを別のノードに割り当てようとします。ILMがインデックスをシュリンクしたが、閾値期間中にシュリンクされたインデックスのシャードを再割り当てできなかった場合、ILMはシュリンクされたインデックスを削除し、shrink アクション全体を再試行します。