[解決済み] クラスタのインデックスの名前を変更する方法は？

質問内容

クラスタ内のいくつかのインデックスの名前を変更する必要があります（その名前 必須 を使用することはできません。 エイリアス ).

サポートされている方法はないと見ましたが、一番近いのは インデックスのディレクトリをリネームする クラスタで試してみました。

クラスタには3台のマシンがあります A , B と C で、それぞれにシャードがレプリケートされています。のelasticsearchをシャットダウンしました。 A という名前に変更し /var/lib/elasticsearch/security/nodes/0/indices/oldindexname から /var/lib/elasticsearch/security/nodes/0/indices/newindexname を起動し、再起動 A .

クラスタの状態は黄色で、elasticsearchは正しい状態を復元するためにいくつかのマジックを行っていました。しばらくして、私は以下のような状態になりました。

• oldindexname が利用可能で、完全に複製されている（から回復した B と C だろう)
• newindexname しかし、headプラグインはそのシャードが"Unassigned"の状態であり、グレーアウトしている（複製されていない）ことを示しています。

リカバリ中 security.log は次のようなメッセージを表示しました。

[2015-02-20 11:02:33,461][INFO ][gateway.local.state.meta ] [A.example.com] dangled index directory name is [newindexname], state name is [oldindexname], renaming to directory name

一方 newindexname は検索可能ですが、正常な状態でないことは確かです。

を削除して、以前の状態にロールバックしました。 newindexname . クラスタは、"Unassigned"エントリなしで緑に戻りました。

そうすると、どうすれば oldindexname から newindexname をクラスターで使用することはできますか？

注意 私が考えている究極の解決策は、スクロールコピーすることです。 oldindex を newindex を削除し oldindex を後回しにする。これは時間がかかるので、もっと直接的な解決策があれば最高です。

解決方法は？

ElasticSearch 7.4から、インデックスの名前を変更する最も良い方法は、新しく導入された クローンインデックスAPI を使用して元のインデックスを削除し、次に インデックス削除API .

同じ目的で Snapshot API や Reindex API を使用した場合と比較した場合の Clone Index API の主な利点は速度です。Clone Index API はソースインデックスからターゲットインデックスへセグメントをハードリンクし、その内容を一切再処理しないからです (ハードリンクをサポートしているファイルシステム上では当然ですが。それ以外の場合はファイルはファイルシステムレベルでコピーしますが、他の方法に比べてはるかに効率がよいのです)。Clone Indexはまた、ターゲットインデックスがソースインデックスとあらゆる点で同一であることを保証します（つまり、Reindexアプローチとは逆に、設定やマッピングを手動でコピーする必要はありません）。また、ローカルのスナップショットディレクトリを設定する必要もありません。

余談です。 この手順は、以前のソリューションよりもはるかに高速ですが、それでもダウンタイムを意味します。インデックスの名前を変更することを正当化する実際のユースケース（たとえば、分割、縮小、バックアップのワークフローにおけるステップ）がありますが、インデックスの名前の変更は日常的な操作の一部であるべきではありません。もし、ワークフローで頻繁にインデックスの名前を変更する必要があるのであれば、以下の使用を検討すべきです。 インデックスエイリアス 代わりに

以下は、インデックスの名前を変更する一連の操作の例です。 source_index から target_index . これはElasticSearch専用のコンソールを使って実行することができます。 をKibanaで表示します。 . 参照 このgist を使用したこの例の別バージョンもあります。 curl Elastic Searchコンソールの代わりに

# Make sure the source index is actually open
POST /source_index/_open

# Put the source index in read-only mode
PUT /source_index/_settings
{
  "settings": {
    "index.blocks.write": "true"
  }
}

# Clone the source index to the target name, and set the target to read-write mode
POST /source_index/_clone/target_index
{
  "settings": {
    "index.blocks.write": null 
  }
}

# Wait until the target index is green;
# it should usually be fast (assuming your filesystem supports hard links).
GET /_cluster/health/target_index?wait_for_status=green&timeout=30s

# If it appears to be taking too much time for the cluster to get back to green,
# the following requests might help you identify eventual outstanding issues (if any)
GET /_cat/indices/target_index
GET /_cat/recovery/target_index
GET /_cluster/allocation/explain

# Delete the source index
DELETE /source_index