記事名:Elasticsearch Reference[2.2]

原文アドレス:https://www.elastic.co/guide/en/elasticsearch/reference/2.2/setup-upgrade.html

訳者:code 4 j

アップグレード

アップグレードする前に注意してください:

バージョン変更文書を参照してください.

をアップグレードする前に、開発環境でアップグレードバージョンをテストしてください.

アップグレード前のバックアップデータ.バックアップをしないと、前のバージョンにロールバックできません.

Elasticsearchでは、通常、スクロールアップグレードステップを使用できます.サービスは中断されません.この章では、スクロールアップグレードとダウンタイムアップグレードの方法について詳しく説明します.
現在のバージョンでスクロールアップグレードがサポートされているかどうかは、次の表を参照してください.
アップグレード前
アップグレード後
サポートされるアップグレード方法
0.90.x
2.x
クラスタアップグレードの停止
1.x
2.x
クラスタアップグレードの停止
2.x
2.y
スクロールアップグレード(y>x)

データのバックアップ

アップグレードする前によくバックアップをしてください.そうすれば、問題が発生したらロールバックできます.アップグレードにはLuceneバージョンのアップグレードも含まれている場合があります.Luceneのアップグレード後に更新されたインデックスは、元のバージョンのElasticsearchでは走れない可能性があります.

1.0以降のバージョンのバックアップ

1.0以降のバージョンでバックアップを行うには、スナップショットを使用すると便利です.詳細は、backup and restore with snapshotsを参照してください.

バックアップ0.9および以前のバージョン

バックアップ0.90.xバージョンの手順は次のとおりです.
ステップ1:
次のステップでは、バックアップ時にインデックスがディスクにリフレッシュされないようにします.

PUT /_all/_settings
{
  "index": {
    "translog.disable_flush": "true"
   }
}

ステップ2:
次のステップでは、クラスタのバックアップ時に、データが1つのノードから別のノードにバランスすることを防止します.

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

ステップ3:データのバックアップ
再バランスとインデックスリフレッシュが無効になったら、好きな方法でデータのバックアップを開始します(tarパッケージに電話して、ストレージスナップショットまたはバックアップソフトウェアを使用します).
ステップ4:再バランスとインデックスのリフレッシュを再開
バックアップが完了すると、Elasticsearchからデータを読み込む必要がなくなり、再バランスとインデックスリフレッシュを再開する必要があります.

PUT /_all/_settings
{
  "index": {
    "translog.disable_flush": "false"
  }
}

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

スクロールアップグレード

スクロールアップグレードでは、Elasticsearchクラスタのノードを1つずつアップグレードでき、ダウンタイムを必要としません.クラスタでは、スライスが新しいバージョンから古いバージョンのノードに割り当てられないため、複数のバージョンを同時に実行することはサポートされていません.
このリストから、現在のバージョンのESがスクロールアップグレードをサポートしているかどうかを確認します.
スクロールアップグレードの手順は次のとおりです.

ステップ1:スライス再平衡を無効にする

ノードを閉じると、スライス割り当てプロセスによって現在のノードからクラスタの別のノードにスライスがコピーされ、I/O操作が無駄になります.このプロパティは、ノードを閉じる前に無効にできます.

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

ステップ2:不要なインデックスを停止し、同期リフレッシュを実行します(このステップはオプション).
アップグレード中にインデックス操作を楽しむことができます.もちろん、次のコマンドを使用すると、不要なインデックスを停止し、同期リフレッシュを実行すると、スライスリカバリの速度が速くなります.
POST/_flush/synced
同期リフレッシュは、花を添える操作です.インデックスが保留されている場合は、操作が失敗します.安全のために何度も試してみる必要があります.
ステップ3:単一ノードのダウンタイムとアップグレード
アップグレード前にノードを閉じます.
注意:zipまたはtarパッケージを使用してアップグレードすると、デフォルトではElasticsearchホームディレクトリのconfig、data、log、pluginsなどのディレクトリが上書きされます.異なるディレクトリに解凍したほうがいいです.これにより、アップグレード中に元のディレクトリが削除されません.カスタムディレクトリはpath.confとpath.dataで設定します.RPMまたはDEBパッケージは、ディレクトリを適切な場所に配置します.
rpm/debインストールパッケージを使用してアップグレード:

rpmまたはdpkgを使用して新しいパッケージをインストールすると、すべてのディレクトリが適切な場所に配置され、プロファイルが上書きされません.

zipまたはtarパッケージを使用してインストールを解凍します.

インストールパッケージを解凍し、configおよびdataディレクトリを上書きしないようにします.

古いインストールディレクトリからconfディレクトリを新しいインストールディレクトリにコピーするか、--path.confオプションを使用して外部のconfigディレクトリ

にコピーする.

古いインストールディレクトリからdataディレクトリを新しいインストールディレクトリにコピーするか、config/elasticsearch.ymlのpath.dataを変更してdataディレクトリを元のディレクトリに設定します.

ステップ4:アップグレードされたノードの起動
アップグレード後のノードを起動し、クラスタへの参加を確認するには、ログまたは次のコマンドを使用します.
GET _cat/nodes
ステップ4:スライスを再開してバランスをとる
ノードがクラスタに追加されると、次のコマンドを使用してスライス再バランスを再起動します.

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

ステップ6:ノードが正常に戻るのを待つ
クラスタスライスバランスが終了するのを待って、次のノードをアップグレードします.この手順では、次のコマンドを使用して確認できます.
GET _cat/health statusの列がyellowからgreenになるまで、Greenはプライマリスライスとレプリカの割り当てが完了したことを示します.
ポイント:スクロールアップグレード中、高バージョンのプライマリ・スライスは、高バージョンのデータ・フォーマットの古いバージョンが認識されていないため、低バージョンのノードにコピーを割り当てません.高バージョンのプライマリスライスがレプリカを割り当てられない場合、すなわちクラスタに高バージョンのノードが1つしか残っていない場合、ノードは未割り当ての状態を維持し、クラスタの健康はyellowを維持する.この場合、初期化またはスライス割り当てが実行されているかどうかを確認します.別のノードのアップグレードが終了すると、スライスが割り当てられ、クラスタ状態はgreenに回復する.
同期リフレッシュを使用していないスライスリカバリ時間は遅くなります.スライスの状態は、_cat/recoveryによって監視を要求することができる.
GET _cat/recovery
第七部:上記手順を繰り返す
クラスタが安定し、ノードが回復すると、残りのノードに対して上記の手順を繰り返す.

クラスタアップグレードの停止

大バージョンのElasticsearchをアップグレードする場合は、クラスタの再起動を停止する必要があります:0から.xから1.xまたは1.xから2.xなど.スクロールアップグレードでは、大きなバージョンにわたるクラスタはサポートされていません.ダウンタイム・グループのアップグレードは、次の手順に従います.
ステップ1:スライス割当ての無効化
ノードを閉じると、スライス割り当てプロセスによって現在のノードからクラスタの別のノードにスライスがコピーされ、I/O操作が無駄になります.このプロパティは、ノードを閉じる前に無効にできます.

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

0.90からxを1にアップグレードx、以下の構成を使用します.

PUT /_cluster/settings
{
  "persistent": {
    "cluster.routing.allocation.disable_allocation": true,
    "cluster.routing.allocation.enable": "none"
  }
}

ステップ2:同期リフレッシュの実行
不要なインデックスを停止し、同期リフレッシュを実行すると、スライス・リカバリが高速になります.
POST/_flush/synced
同期リフレッシュは、花を添える操作です.インデックスが保留されている場合は、操作が失敗します.安全のために何度も試してみる必要があります.
ステップ3:すべてのノードを閉じてアップグレードします.
クラスタのすべてのノードのESサービスをオフにし、各ノードはスクロール再起動と同じ方法で各ノードをアップグレードします.
ステップ4:クラスタの起動
専用のmasterノード群(masterノードがnode.masterがtrueでnode.dataがfalseのノード)がある場合は、まず起動したほうがいいです.クラスタが形成され、プライマリノードが選択されるのを待っています.このプロセスはログチェックに合格します.
最小選択可能なプライマリノード数に達すると、クラスタが形成され、プライマリノードが選択されます.その後、_cat/healthおよび_cat/nodes APIモニタノードを介して鶏の群れに加わることができる.
GET _cat/health GET _cat/nodes
上記のAPIを使用して、ノードがクラスタに正常に参加したかどうかを確認します.
ステップ5:クラスタがyellowに回復するのを待つ
ノードがクラスタに追加されると、ノード上のプライマリスライスはローカルでリカバリを開始します.最初の_cat/healthはredの状態に戻り、プライマリスライスがまだ割り当てられていないことを示します.各ノードのローカルスライスが回復すると、ステータスはyellowになり、すべてのプライマリスライスが割り当てられていることを示しますが、すべてのコピーが割り当てられているわけではありません.これが期待される効果で、結局スライスバランスは無効になっています.
ステップ6:バランスの再起動
すべてのノードがクラスタに参加するまでレプリカの割り当てを遅らせると、masterはローカルのスライスコピーがあるノードにレプリカを割り当てることができます.このとき,すべてのノードがクラスタ内にあり,スライスバランスを再起動するのに安全である.

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

0.90からxを1にアップグレードx、以下の構成を使用します.

PUT /_cluster/settings
{
  "persistent": {
    "cluster.routing.allocation.disable_allocation": false,
    "cluster.routing.allocation.enable": "all"
  }
}

クラスタは、すべてのノードにコピーの割り当てを開始し、インデックスと検索操作が安全になります.しかし、リカバリが終了してからインデックススライスを操作すると、リカバリが速くなります._cat/healthと_cat/recoveryでこのプロセスを監視できます_cat/healthが結果を返すstatus列がgreenを返すと、すべてのプライマリスライスおよびレプリカが割り当てられたことを示す.