既存のインデックスの管理（Manage existing indices）

既存のインデックスの管理

Curatorや他のメカニズムを使用して定期的なインデックスを管理している場合、ILMに移行する際にいくつかのオプションがあります：

• 新しいインデックスを管理するためにILMポリシーを使用するようにインデックステンプレートを設定します。ILMが現在の書き込みインデックスを管理している場合、古いインデックスに適切なポリシーを適用できます。
• ILM管理インデックスに再インデックスします。

Curatorバージョン5.7以降、CuratorはILM管理インデックスを無視します。

既存の時系列インデックスにポリシーを適用

ILMを使用して定期的なインデックスを管理するための最も簡単な方法は、新しいインデックスにライフサイクルポリシーを適用するためにインデックステンプレートを構成することです。書き込み先のインデックスがILMによって管理されるようになると、古いインデックスに手動でポリシーを適用することができます。

古いインデックス用にロールオーバーアクションを省略した別のポリシーを定義します。ロールオーバーは新しいデータの行き先を管理するために使用されるため、適用されません。

既存のインデックスに適用されたポリシーは、各フェーズのmin_ageをインデックスの元の作成日と比較し、複数のフェーズを即座に進行する可能性があります。ポリシーが強制マージのようなリソース集約的な操作を実行する場合、ILMに切り替えるときに多くのインデックスが同時にこれらの操作を実行することは望ましくありません。

既存のインデックスに使用するポリシーで異なるmin_age値を指定するか、index.lifecycle.origination_dateを設定してインデックスの年齢がどのように計算されるかを制御できます。

すべてのILM以前のインデックスが年齢を経て削除されたら、それらを管理するために使用したポリシーを削除できます。

BeatsやLogstashを使用している場合、バージョン7.0以降でILMを有効にすると、新しいインデックスを自動的に管理するようにILMが設定されます。Logstashを通じてBeatsを使用している場合、新しいデータにILMを使用するためにLogstashの出力設定を変更し、Beatsのセットアップを呼び出す必要があるかもしれません。

管理インデックスへの再インデックス

既存のインデックスにポリシーを適用する代わりに、データをILM管理インデックスに再インデックスすることができます。非常に少量のデータで定期的なインデックスを作成することが過剰なシャード数につながった場合や、同じインデックスに継続的にインデックスすることが大きなシャードとパフォーマンスの問題を引き起こした場合に、これを行いたいかもしれません。

まず、新しいILM管理インデックスを設定する必要があります：

• 1. インデックステンプレートを更新して必要なILM設定を含めます。
• 2. 書き込みインデックスとして初期インデックスをブートストラップします。
• 3. 古いインデックスへの書き込みを停止し、ブートストラップされたインデックスを指すエイリアスを使用して新しいドキュメントをインデックスします。

管理インデックスに再インデックスするには：

• 1. ILM管理インデックスに新しいデータと古いデータを混在させたくない場合は、新しいドキュメントのインデックスを一時停止します。1つのインデックスに古いデータと新しいデータを混在させることは安全ですが、結合されたインデックスは新しいデータを削除する準備ができるまで保持する必要があります。
• 2. ロールオーバーチェックを待っている間にインデックスが大きくなりすぎないように、ILMポーリング間隔を短縮します。デフォルトでは、ILMは10分ごとにどのアクションを実行する必要があるかを確認します。

Python

resp = client.cluster.put_settings(
   persistent={
   "indices.lifecycle.poll_interval": "1m"
   },
  )
  print(resp)

Ruby

response = client.cluster.put_settings(
   body: {
   persistent: {
   'indices.lifecycle.poll_interval' => '1m'
   }
   }
  )
  puts response

Js

const response = await client.cluster.putSettings({
   persistent: {
   "indices.lifecycle.poll_interval": "1m",
   },
  });
  console.log(response);

Console

PUT _cluster/settings
  {
   "persistent": {
   "indices.lifecycle.poll_interval": "1m"
   }
  }

• 3. reindex APIを使用してデータを再インデックスします。元のインデックスにインデックスされた順序でデータをパーティション分けしたい場合は、別々の再インデックスリクエストを実行できます。
  ドキュメントは元のIDを保持します。自動生成されたドキュメントIDを使用せず、複数のソースインデックスから再インデックスする場合、ドキュメントIDが衝突しないように追加の処理が必要になるかもしれません。これを行う1つの方法は、再インデックス呼び出しでスクリプトを使用して、元のインデックス名をドキュメントIDに追加することです。

Python

resp = client.reindex(
   source={
   "index": "mylogs-*"
   },
   dest={
   "index": "mylogs",
   "op_type": "create"
   },
  )
  print(resp)

Ruby

response = client.reindex(
   body: {
   source: {
   index: 'mylogs-*'
   },
   dest: {
   index: 'mylogs',
   op_type: 'create'
   }
   }
  )
  puts response

Js

const response = await client.reindex({
   source: {
   index: "mylogs-*",
   },
   dest: {
   index: "mylogs",
   op_type: "create",
   },
  });
  console.log(response);

Console

POST _reindex
  {
   "source": {
   "index": "mylogs-*"
   },
   "dest": {
   "index": "mylogs",
   "op_type": "create"
   }
  }

• 4. 再インデックスが完了したら、マスターノードへの不要な負荷を防ぐためにILMポーリング間隔をデフォルト値に戻します：

Python

resp = client.cluster.put_settings(
   persistent={
   "indices.lifecycle.poll_interval": None
   },
  )
  print(resp)

Ruby

response = client.cluster.put_settings(
   body: {
   persistent: {
   'indices.lifecycle.poll_interval' => nil
   }
   }
  )
  puts response

Js

const response = await client.cluster.putSettings({
   persistent: {
   "indices.lifecycle.poll_interval": null,
   },
  });
  console.log(response);

Console

PUT _cluster/settings
  {
   "persistent": {
   "indices.lifecycle.poll_interval": null
   }
  }

• 5. 同じエイリアスを使用して新しいデータのインデックスを再開します。
  このエイリアスを使用してクエリを実行すると、新しいデータとすべての再インデックスされたデータが検索されます。
• 6. すべての再インデックスされたデータが新しい管理インデックスで利用可能であることを確認したら、古いインデックスを安全に削除できます。