Elasticsearch: Elasticsearch をアップグレードする最も安全な方法

Elasticsearch クラスターをアップグレードするには、さまざまな方法があります。多くはローリング アップグレードを伴うか、クラスターの再起動が必要です。これはより複雑なプロセスです。一般に、考えられるシナリオは 2 つあります。

• ローリング アップグレード (ダウンタイムなし)
• クラスター全体が再起動します (ダウンタイムが発生します)。

 メジャー バージョンの最後のマイナー バージョン (6.8 など) が次のメジャー バージョン (7.0 など) の最初のマイナー バージョンにアップグレードされる場合は、ローリング イン タイムでアップグレードできます。そうでない場合は、全体を再起動する必要があります。集まる：

一般に、アップグレードにはアップグレード アシスタントを使用できます。

ローリング アップグレードには次の手順が含まれます。

1. クラスターをバックアップする
2. 不要なインデックス作成を停止します (可能であれば)
3. シャード割り当てを無効にする
4. ノードを停止して更新する
5. 開始ノード
6. シャード割り当てを再度有効にして待ちます
7. ステップ 3 を繰り返します (すべてのノードが更新されるまで)

これは一般的なケースでは非常にうまく機能し、公式に推奨される手順です。次の方法でシャードの割り当てを禁止できます。

PUT _cluster/settings
{
  "transient": {
    "cluster.routing.allocation.enable": "primaries"
  }
}

POST _flush/synced

次の方法でシャードの割り当てを再開できます。

PUT _cluster/settings
{
  "transient": {
    "cluster.routing.allocation.enable": "all"
  }
}

次の方法でクラスターの健全性ステータスをクエリできます。

GET _cat/health

複数のノードを更新する場合は、ステータスが緑色になるまで待ってから、次のノードの更新を続行する必要があります。

クラスター全体を再起動するには、次の手順が必要です。

1. インデックス作成を停止します (書き込みを無効にする、または ES にアクセスできないようにするなど)
2. シャード割り当てを無効にします (再起動後に以前の設定が失われないように、必ず「persistent」を使用してください)
3. 同期リフレッシュを実行する
4. すべてのノードをシャットダウンして更新します (ダウンタイムが開始されました)
5. すべての専用マスターノードを開始します (ダウンタイム連絡)
6. 他のノードを起動する
7. 黄色を待つ
8. シャード割り当てを再度有効にする

ダウンタイムなしで Elasticsearch をアップグレードする推奨方法はローリング アップグレードです。上記のローリング アップグレードの手順を詳しく見てみましょう。ただし、データ ノードが再起動されるたびに黄色のクラスター ステータスが表示され、これは危険であることを意味します。

より安全なアプローチを取ることができます。計画では、すべてのシャードを別のノードに割り当て、空のデータ ノードをアップグレードするだけです。こうすることで、クラスターは可能な限り緑色のままになります。はじめましょう！

 

 

手順については、以下で詳しく説明します。

ステップ—: シャードを他のノードに割り当てる

クラスターレベルのシャード割り当てのおかげで、シャードをあるノードから別のノードに移動できます。ノード名と IP アドレスを使用できます。

PUT _cluster/settings
{
  "transient": {
    "cluster.routing.allocation.exclude._name": "node-1"
  }
}

シャード割り当てのプロセスは、回復 APIを呼び出すことで確認できます。

GET _cat/recovery?v&h=index,shard,time,source_node,target_node,fp,bp&s=ty:desc,index,bp:desc&active_only

割り当て APIを呼び出すことで、各ノードにあるシャードの数を確認できます。

GET /_cat/allocation?v&h=shards,node,disk.avail,disk.total,disk.percent,&s=node

注: Elasticsearch は、より高いバージョンのノードにレプリカ シャードを割り当てることはできません。たとえば、ノードがバージョン 8 でインデックスのプライマリ シャードを保持している場合、インデックス レプリカ シャードをバージョン 7 のノードに割り当てることはできません。これは、未割り当てのレプリカ シャードがいくつかある可能性があり、レプリカ シャードが 2 つになるまでクラスターが黄色に変わることを意味します。データノード。

{
  "decider" : "node_version",
  "decision" : "NO",
  "explanation" : "cannot allocate replica shard to a node with version [7.10.1] since this is older than the primary version [7.17.7]"
}

ステップ 2: データ ノードをアップグレードする

すべてのシャードが他のノードに割り当てられている場合、データ ノードを安全にアップグレードできます。アップグレードする前にすべてのプラグインを削除する必要があり、アップグレード後にすべてのプラグインを再インストールする必要があります。elasticsearch-plugin install コマンドを使用すると、Elasticsearch がプラグインを自動的にダウンロードしてインストールします。インスタンスにインターネット アクセスがない場合は、プラグインをダウンロードしてオフラインでインストールできます。

注: データ ノードまたはマスター ノードにプラグインがインストールされていない場合は、elasticsearch サービスを開始できません。コーディネーター ノードには注意してください。最初はプラグインに関連するエラーは表示されませんが、検索とインデックス作成が開始されると、プラグインに関連するエラーが表示されます。

[2023-07-04T08:07:07,906][WARN ][o.e.t.TransportService   ] [es-prod-coor-1] Transport response handler not found of id [21252]
[2023-07-04T08:07:07,902][WARN ][o.e.t.InboundHandler     ] [es-prod-coor-1] Failed to deserialize response from [ip/ip:9300]
org.elasticsearch.transport.TransportSerializationException: Failed to deserialize response from handler [org.elasticsearch.transport.TransportService$ContextRestoreResponseHandler/org.elasticsearch.transport.TransportService$4/[indices:data/read/search[phase/query]]:org.elasticsearch.action.search.SearchTransportService$ConnectionCountingHandler@5ae8f1a6/org.elasticsearch.action.search.SearchExecutionStatsCollector/org.elasticsearch.action.search.AbstractSearchAsyncAction$1@f51f168]
Caused by: java.lang.IllegalArgumentException: Unknown NamedWriteable [org.elasticsearch.search.DocValueFormat][collate]
java.lang.IllegalStateException: Message not fully read (response) for requestId [4288], handler [org.elasticsearch.transport.TransportService$ContextRestoreResponseHandler/org.elasticsearch.transport.TransportService$4/[indices:data/read/search[phase/query]]:org.elasticsearch.action.search.SearchTransportService$ConnectionCountingHandler@7518541f/org.elasticsearch.action.search.SearchExecutionStatsCollector/org.elasticsearch.action.search.AbstractSearchAsyncAction$1@cd2eb6d], error [false]; resetting

 

ステップ 3: シャードにアップグレードされたデータ ノードの割り当てを許可する

 

Q&A

Q1: Elasticsearch のアップグレード プロセスを高速化するにはどうすればよいですか?

A1 : indices.recovery.max_bytes_per_sec を増やすことができます。同時に回復するノードの数を増やすこともできます。これは私が使用するクラスター設定です。

PUT _cluster/settings
{
  "persistent": {
    "cluster.routing.allocation.cluster_concurrent_rebalance": "2",
    "cluster.routing.allocation.node_concurrent_incoming_recoveries": "3",
    "cluster.routing.allocation.node_concurrent_outgoing_recoveries": "10",
    "indices.recovery.max_bytes_per_sec": "250mb",
    "indices.recovery.max_concurrent_file_chunks": "5"
  }
}

Q2: アップグレードプロセス中に不必要なシャードのリバランスが大量に行われますが、停止できますか?

A2 : はい、アップグレード プロセス中にシャードのリバランスを無効にすることができます。クラスター設定のcluster.routing.rebalance.enableをnoneに更新します。
https://www.elastic.co/guide/en/elasticsearch/reference/current/modules-cluster.html#shards-rebalancing-settings

Q3: クラスター上に Elasticsearch の複数のバージョンがあっても安全ですか?

A3 : 設計上、クラスター上に複数のバージョンの Elasticsearch を保持できます。ベスト プラクティスとして、クラスターがアップグレードされるまでは異なるバージョンのみを保持することをお勧めします。

Q4: elasticsearch-oss から elasticsearch 基本ライセンスにアップグレードできますか?

A4 : はい、Elasticsearch オープン ソース ソフトウェアからベーシック バージョンに安全にアップグレードできます。たとえば、elasticsearch-oss v7.10.2 を elasticsearch Basic 7.17.11 にアップグレードできます。

Q5: Elasticsearch 7.10.2 から 8.x にアップグレードできますか?

A5 : はい、お勧めしません。まず最新バージョン 7.17.x にアップグレードすると、非推奨ログが表示されます。非常に便利な Kibana Upgrade Assistant を使用することもできます。
https://www.elastic.co/guide/en/kibana/current/upgrade-assistant.html

Q6: Elasticsearch をダウングレードできますか?

A6：いいえ。一度アップグレードすると、ダウングレードすることはできません。つまり、ダウングレードすることはできますが、elasticsearch サービスを開始することはできません:)。唯一可能な方法は、新しいクラスターを作成し、クラスターからデータを移行するか、スナップショット/復元することです。したがって、アップグレードする前に慎重に検討し、非推奨がないか確認し、アプリケーションが Elasticsearch の新しいバージョンと互換性があることを確認してください。

Q7: バージョンアップ間の主な変更点は何ですか?

A7 : メジャー バージョンとマイナー バージョンの間には重大な変更がいくつかあります。このリンクですべてを見つけることができます。マイナーアップグレード: 7.16.x から 7.17.x など。通常、マイナー アップグレードでは、以前のマイナー バージョンとの互換性を維持しながら、新機能、改善、バグ修正が導入されます。メジャー アップグレード: 7.17.x から 8.8.x など。通常、メジャー アップグレードには重大な変更が含まれます。これには、API の重大な変更、データ移行要件、およびアップグレードに追加の手順が必要となるその他の変更が含まれる場合があります。したがって、データ パイプラインとアプリケーションが新しいバージョンと互換性があることを確認してください。:)

• https://www.elastic.co/support/matrix
• https://www.elastic.co/guide/en/elasticsearch/reference/8.8/migration-8.0.html

Q8: マイナー リリース間に大きな変更はありますか?

A8 : 正確には違います。重大な変更は、クラスターに影響を与える可能性のあるメジャー バージョンのアップグレードの間にのみ存在します。