フィードバックを送信
Upgrading Elasticsearch
ご覧のページは、お客様の利便性のために一部機械翻訳されています。また、ドキュメントは頻繁に更新が加えられており、翻訳は未完成の部分が含まれることをご了承ください。最新情報は都度公開されておりますため、必ず英語版をご参照ください。翻訳に問題がある場合は、 こちら までご連絡ください。

Elasticsearchのバックアップ

Elasticsearch レプリカ はノードのダウンから保護しますが、壊滅的な障害の場合には役に立ちません。 その時に役立つのは、適切なバックアップ習慣だけです。

アップグレード前のインデックスのバックアップ

インデックス化されたデータが Liferay のデータベースから再インデックス化することで復元できる場合でも、すべてのアップグレード シナリオでインデックスをバックアップすることがベスト プラクティスです。 データが検索インデックスにのみ保存されている場合は、アプリ固有のインデックス （Liferay DXP 7.2 および 7.3 の Liferay 検索チューニングインデックスなど）の スナップショットを取得することが不可欠です。 スナップショットは、新しいElasticsearchサーバをセットアップする際に、以前のデータ（同義語セットや結果ランキングなど）を復元するために使用することができます。 このアプローチを試す前に、Elasticsearch のドキュメント スナップショットとバージョン互換性の復元 を必ず読んでください。

ここでは、代表的なアップグレードシナリオを紹介します。

  • Liferayとは無関係にElasticsearchクラスタをアップグレードする場合：すべてのインデックスのバックアップを推奨します。 スナップショットからのデータの復元は、すべてのインデックスがシステムに残っているため、必要ありません。

  • Liferayをアップグレードし、同じElasticsearchクラスタに接続する場合：すべてのインデックスのバックアップを行うことを推奨します。 スナップショットからのデータの復元は、すべてのインデックスがシステムに残っているため、必要ありません。

  • Liferayをアップグレードし、別のElasticsearchクラスタに接続する場合：すべてのインデックスのバックアップを推奨します。 スナップショットからのリストアは、すべてのプライマリストレージインデックスに必要です。 Liferay の検索チューニング機能（結果のランキングと同義語セット）のいずれかを使用している場合は、Liferay DXP 7.4 にアップグレードした後、 インデックス付きデータを Liferay データベースにインポート する必要もあります。

Elasticsearchクラスタのバックアップを作成する

次の3つの手順でElasticsearchクラスターをバックアップし、バックアップの復元をテストします。

  1. リポジトリを作成します

  2. Elasticsearchクラスターのスナップショットを作成します

  3. スナップショットから復元します

注

詳細については、Elastic の Elasticsearch 管理ガイド、特に スナップショットおよび復元モジュールを参照してください。

リポジトリの作成

まず、スナップショットを保存するためのリポジトリ を作成します 。 Elasticsearchでは、以下のリポジトリタイプが利用可能です。

  • ネットワークファイルシステムやNASなどの共有ファイルシステム
  • Amazon S3
  • HDFS（Hadoop Distributed File System）
  • Azureクラウド
  • Google Cloud Storage

スナップショットを共有ファイルシステムに保存する場合は、まず、 path.repo 設定を使用して、各ノードの elasticsearch.yml に共有ファイルシステムへのパスを登録します。 例:

path.repo: ["path/to/shared/file/system/"]

リポジトリをホストするフォルダへのパスを登録した後（フォルダが存在していることを確認してください）、PUTコマンドでリポジトリを作成します。 例:

PUT /_snapshot/test_backup
{
  "type": "fs",
  "settings": {
    "location": "/path/to/shared/file/system/"
  }
}'

test_backup を作成するリポジトリの名前に置き換え、 location 設定値を共有ファイルシステムへの絶対パスに置き換えます。

リポジトリが正しく作成されていれば、コマンドは次のような結果を返します。

{"acknowledged":true}

リポジトリが存在しているので、スナップショットを作成します。

クラスターのスナップショットを取得する

最も簡単なスナップショットのアプローチは、クラスター内のすべてのインデックスの スナップショットを作成することです。 例:

PUT /_snapshot/test_backup/snapshot_1

スナップショットコマンドが成功すると、次の結果が返されます。

{"accepted":true}

スナップショットを特定のインデックスに制限することもできます。 たとえば、Liferay Enterprise Searchモニタリングを使用しているが、スナップショットからモニタリングインデックスを除外したい場合があります。 スナップショットに含めるインデックスを明示的に宣言できます。 例:

PUT /_snapshot/test_backup/snapshot_2
{ "indices": "liferay-0,liferay-20116" }

すべてのインデックスとそのメトリックを一覧表示するには、次のコマンドを実行します。

GET /_cat/indices?v

インデックスメトリクスの例：

health status index                                              uuid                   pri rep docs.count docs.deleted store.size pri.store.size
green  open   liferay-20101-search-tuning-rankings               ykbNqPjkRkq7aCYnc7G20w   1   0          7            0      7.7kb          7.7kb
green  open   liferay-20101-workflow-metrics-tokens              DF-1vq8IRDmFAqUy4MHHPQ   1   0          4            0       26kb           26kb
green  open   liferay-20101                                      QKXQZeV5RHKfCsZ-TYU-iA   1   0     253015          392     43.1mb         43.1mb
green  open   liferay-20101-workflow-metrics-sla-task-results    SrWzmeLuSKGaIvKrv4WmuA   1   0          4           72     30.6kb         30.6kb
green  open   liferay-20101-workflow-metrics-processes           Ras8CH0PSDGgWSyO3zEBhg   1   0          1            0     49.3kb         49.3kb
green  open   liferay-20101-workflow-metrics-nodes               bcdKKgDySeWf4BJnmMzk6A   1   0          4            0     10.5kb         10.5kb
green  open   liferay-20101-workflow-metrics-sla-process-results VJrNOpJWRoeTaJ-sBGs_vA   1   0          3           91     47.4kb         47.4kb
green  open   liferay-20101-workflow-metrics-instances           OgJMyD5ZQIi2h0xUTSjezg   1   0          3            0     62.4kb         62.4kb
green  open   liferay-0                                          jPIEOfZhSCKZSWnY0L65RQ   1   0     253114          491     50.1mb         50.1mb
green  open   liferay-20101-search-tuning-synonyms               pAUN8st1RmaV1NxXtj-Sig   1   0          1            0      4.1kb          4.1kb
注

Elasticsearch は スマート スナップショット アプローチを使用します。 その意味を理解するために、1つのインデックスを考えてみましょう。 最初のスナップショットにはインデックス全体のコピーが含まれ、それ以降のスナップショットには、最初の完全なインデックススナップショットと現在のインデックスの状態との差分のみが含まれます。

最終的には、リポジトリに多数のスナップショットが作成されることになります。スナップショットに名前を付けたとしても、スナップショットに含まれているものを忘れてしまう可能性があります。 Elasticsearch APIを使用して説明を取得できます。 例:

GET /_snapshot/test_backup/snapshot_1

以下が返されます

{"snapshots":[
    {"snapshot":"snapshot_1",
    "uuid":"WlSjvJwHRh-xlAny7zeW3w",
    "version_id":6.80399,
    "version":"6.8.2",
    "indices":["liferay-20099","liferay-0","liferay-47206"],
    "state":"SUCCESS",
    "start_time":"2018-08-15T21:40:17.261Z",
    "start_time_in_millis":1534369217261,
    "end_time":"2018-08-15T21:40:17.482Z",
    "end_time_in_millis":1534369217482,
    "duration_in_millis":221,
    "failures":[],
    "shards":{
        "total":3,
        "failed":0,
        "successful":3

        }
    }
]}

スナップショット情報には、インデックスの時間範囲が含まれています。

スナップショットを破棄したい場合は、DELETEコマンドを使用します。

DELETE /_snapshot/test_backup/snapshot_1

スナップショットにすべてのインデックスを含めると、多くの時間とストレージを消費する可能性があります。 誤ってスナップショットの作成を開始した場合（例えば、特定のインデックスにフィルターをかけようとしたが、すべてのインデックスを含めてしまったなど）、DELETEコマンドを使用してスナップショットの処理をキャンセルすることができます。 名前でスナップショットを削除すると、スナップショットプロセスが終了し、部分的なスナップショットがリポジトリから削除されます。

スナップショットからの復元のテスト

壊滅的な障害が発生した場合、そこから 検索インデックスを復元 できないのであれば、スナップショットは役に立ちません。 _restore APIを使用して、すべてのスナップショットのインデックスを復元します。

POST /_snapshot/test_backup/snapshot_1/_restore

スナップショットインデックスから既存のインデックスにデータを復元する必要がある場合は、別の名前でインデックスを復元してから、データを既存のインデックスに再インデックスします。 復元コマンドを特定のインデックスに制限するには、indices オプションを使用します。 rename_pattern および rename_replacement オプションを使用して、復元されたインデックスの名前を変更します。

POST /_snapshot/test_backup/snapshot_1/_restore
{
    "indices": "liferay-20116",
    "rename_pattern": "(.+)",
    "rename_replacement": "restored-$1"
}

これにより、スナップショットからliferay-20116という名前のインデックスのみが復元され、名前がrestored_liferay-20116に変更されます。 クラスターに復元すると、バックアップされたデータを既存のliferay-20116インデックスに復元する_reindex API呼び出しを実行するために使用できます。

POST _reindex/
{
    "dest": {
      "index": "liferay-20116"
    },
    "source": {
      "index": "restored_liferay-201116"
    }
}

スナップショットプロセスのキャンセルと同様に、DELETE コマンドを使用して、誤った復元プロセスをキャンセルすることができます。

DELETE /restored_liferay-20116index_3

本番環境システムでの壊滅的な障害は誰もが望みませんが、スナップショットを取得してインデックスを復元するためのElasticsearchのAPIを使用すれば、障害が発生した場合に検索クラスターを復元できるので安心です。 詳細とオプションについては、Elastic の スナップショットと復元のドキュメントをご覧ください。

Liferay 7.2 および 7.3 の検索チューニングインデックスのバックアップと復元

Elasticsearch インデックスのスナップショットを作成することを強くお勧めします。特に、プライマリ ストレージ形式として機能するインデックスの場合は、スナップショットを作成することを強くお勧めします。たとえば、Liferay DXP 7.2 および 7.3 の シノニム セット および 結果ランキング です。 データベースには、これらのアプリケーションのレコードはありません。 Liferay DXP 7.4 では、データがデータベースに保存されるため、この手順は必要ありません。

Elasticsearch の スナップショットおよび復元 機能を使用して、検索チューニング インデックスをバックアップおよび復元できます。

  1. システムのどこかにelasticsearch_local_backupというフォルダを作成します。 Elasticsearchがフォルダへの読み取りおよび書き込みアクセス権を持っていることを確認します（例： /path/to/elasticsearch_local_backup）。

  2. 追加

    path.repo: [ "/path/to/elasticsearch_local_backup" ]

    Elasticsearch クラスター内の elasticsearch.yml に すべてのマスターノードとデータノード を追加します。 Elasticsearchをアップグレードする場合は、スナップショットリポジトリへのパスがアップグレード前とアップグレード後のElasticsearch構成で同じであることを確認してください。

  3. すべてのElasticsearchノードを再起動します。

  4. スナップショットリポジトリを登録します。 次のsnapshot APIリクエストを実行できます（たとえば、Kibanaの開発ツールコンソールから）。

    PUT /_snapshot/elasticsearch_local_backup
{
  "type": "fs",
  "settings": {
    "location": "/path/to/elasticsearch_local_backup"
  }
}

    新しいElasticsearchバージョンにアップグレードする場合は、アップグレード後のElasticsearchでこれと同じコマンドを使用して、スナップショットリポジトリを登録できます。

  5. スナップショットを作成します:

    PUT /_snapshot/elasticsearch_local_backup/snapshot1?wait_for_completion=true
{
  "indices": "liferay-20101-search-tuning*",
  "ignore_unavailable": true,
  "include_global_state": false
}

    すべての Liferay インデックスのスナップショットを作成する場合は、代わりに "indices": "liferay*,workflow-metrics*" を使用できます。 アップグレードシナリオを使用している場合は、Liferay DXP 7.2および7.3の同義語セットインデックスや結果ランキングインデックスなど、データベースから再作成できないインデックスのみのスナップショットを作成するほうが合理的な場合があります。

  6. 別の名前を使用してスナップショットから特定のインデックスを 復元 するには、次のような 復元 API 呼び出しを実行します。

    POST /_snapshot/elasticsearch_local_backup/snapshot1/_restore
{
  "indices": "liferay-20101-search-tuning-synonyms,liferay-20101-search-tuning-rankings",
  "ignore_unavailable": true,
  "include_global_state": false,
  "rename_pattern": "(.+)",
  "rename_replacement": "restored_$1",
  "include_aliases": false
}

    ここで、indicesには、復元元のスナップショットされているインデックス名を設定します。 上記の呼び出しによるインデックスは、rename_pattern および rename_replacement 正規表現に従って、restored_liferay-20101-search-tuning-rankings および restored_liferay-20101-search-tuning-synonyms として復元されます。

Sidecar/Embedded モードで実行中に検索チューニング構成 (同義語セットや結果のランキングなど) を追加した場合、Elasticsearch への本番モード接続を構成してインデックスを再作成すると、それらの構成は消えます。

既存の検索チューニングインデックスドキュメントを復元するには、次のように Elasticsearch の Reindex APIを使用できます。

POST _reindex/
{
 "dest": {
   "index": "liferay-20101-search-tuning-synonyms"
 },
 "source": {
   "index": "restored_liferay-20101-search-tuning-synonyms"
 }
}

liferay-20101-search-tuning-rankingsインデックスに同じコマンドを実行します。 アップグレード後のElasticsearchインストールで両方のリクエストを実行すると、アップグレード前のシステムから同義語セットと結果ランキングのデータが復元されるようになりました。

検索の調整インデックス名

すぐに使用できる検索の調整インデックス名は、Liferayのバージョンとパッチレベルによって異なります。

Liferayのバージョンとパッチ検索の調整インデックス
Liferay DXP 7.2 SP2/FP5以下liferay-search-tuning-rankings
liferay-search-tuning-synonyms-liferay-<companyId>
Liferay DXP 7.2 SP3/FP8以降liferay-<companyId>-検索チューニングランキング
liferay-<companyId>-検索チューニングシノニム
Liferay DXP 7.3 GA1+ および7.4 GA1+liferay-<companyId>-検索チューニングランキング
liferay-<companyId>-検索チューニングシノニム

<companyId> (例: 20101) は、データベース内の特定の Company レコードに属します。 これは UI では インスタンス ID として表示され、 仮想インスタンスを表します。

次のステップ

Elasticsearch をアップグレードする場合は、今すぐ行うことができます。

Resource Type:
Official Documentation
Feature:
Search
Search Engine Installation and Maintenance
Deployment Approach:
Liferay Self-Hosted