スナップショットと復元 - - Alibaba Cloud ドキュメントセンター

snapshot 操作を使用して、Elasticsearch クラスターをバックアップすることができます。 snapshot 操作では、クラスターの現在のステータスとデータを取得し、共有リポジトリに保存します。バックアッププロセスはインテリジェントに行われます。

最初のスナップショットは、クラスター全体をコピーしたものです。以降のスナップショットでは、既存のスナップショットと新しいデータとの差分のみが保存されます。したがって、新しいスナップショットを作成する場合、バックアップにデータが追加されるか、バックアップからデータが削除されます。つまり、最初のスナップショットを作成するよりも、後続のスナップショットを作成する方がはるかに高速です。

重要このトピックの <1>、<2>、<3> のタグは、コードを説明するための印です。コードを実行する際、これらのタグを削除してください。

前提条件

Elasticsearch クラスターのスナップショットを作成する前に、OSS の有効化を行い、OSS バケットを作成する必要があります。アーカイブタイプの OSS バケットはサポートされていないため、標準の OSS バケットでなければなりません。 OSS バケットと Elasticsearch インスタンスを同じリージョンに作成する必要があります。 OSS バケットの作成

リポジトリの作成

PUT _snapshot/my_backup
{
   "type": "oss",
    "settings": {
        "endpoint": "http://oss-cn-hangzhou-internal.aliyuncs.com", <1>
        "access_key_id": "xxxx",
        "secret_access_key": "xxxxxx",
        "bucket": "xxxxxx", <2>
        "compress": "true",
        "base_path": "snapshot/" <3>
    }
}

<1>：endpoint には、OSS バケットのイントラネットエンドポイントを指定します。詳細は、「リージョンとエンドポイント」の「ECS アクセス用のイントラネットエンドポイント」をご参照ください。
<2>：OSS バケットの名前。既存の OSS バケットでなければなりません。
<3>：base_path フィールドには、リポジトリのパスを指定します。デフォルトはルートディレクトリです。

シャードサイズの設定

大量のデータを OSS にアップロードする必要がある場合、シャードサイズを設定すると、データは複数のシャードに分割された後で OSS バケットにアップロードされます。

POST _snapshot/my_backup/ <1>
{
    "type": "oss",
    "settings": {
        "endpoint": "http://oss-cn-hangzhou-internal.aliyuncs.com",
        "access_key_id": "xxxx",
        "secret_access_key": "xxxxxx",
        "bucket": "xxxxxx",
        "chunk_size": "500mb",
        "base_path": "snapshot/" <2>
    }
}

<1>：PUT メソッドではなく、POST メソッドを呼び出します。 POST メソッドは、リポジトリ設定を更新します。
<2>：base_path フィールドには、リポジトリのパスを指定します。デフォルトはルートディレクトリです。

リポジトリ情報の照会

GET _snapshot

特定のリポジトリの情報を照会するには、GET _snapshot/my_backup を呼び出します。

Elasticsearch クラスターへのスナップショットの移行

スナップショットを Elasticsearch クラスターに移行するには、次の手順に従います。

OSS にスナップショットをバックアップします。
ターゲットクラスターにスナップショットリポジトリを作成します。リポジトリは、スナップショットを保存する OSS バケットを使用する必要があります。
base_path フィールドにスナップショットのパスを設定します。
復元操作を呼び出します。

すべての有効なインデックスのスナップショットの作成

リポジトリには複数のスナップショットが保存されます。スナップショットは、クラスター上のインデックスをコピーしたものです。特定の 1 つ以上のインデックス、またはすべてのインデックスのスナップショットを作成できます。スナップショットを作成するとき、スナップショット名が一意になるようにしてください。

スナップショット操作

基本的なスナップショット操作は、次のとおりです。

PUT _snapshot/my_backup/snapshot_1

この操作では、すべての有効なインデックスのスナップショット snapshot_1 を作成します。このスナップショットは、リポジトリ my_backup に保存されます。この操作は、呼び出した直後に結果が返されます。スナップショット作成プロセスは、バックグラウンドで実行されています。

スナップショットが作成された後に結果が返されるようにする場合、次のように wait_for_completion パラメーターを追加します。

PUT _snapshot/my_backup/snapshot_1? wait_for_completion=true

この操作は、スナップショットが作成されるまで結果は返されません。大きなインデックスのスナップショットを作成する場合、このプロセスには時間がかかります。

特定のインデックスのスナップショットの作成

デフォルトでは、スナップショットにはすべての有効なインデックスが含まれます。 Kibana の場合、ディスク容量の制限により、スナップショットの作成時にすべての診断インデックス (.kibana インデックス) を無視することができます。このタスクを実行するには、次のように、特定のインデックスのスナップショットを作成します。

PUT _snapshot/my_backup/snapshot_2
{
    "indices": "index_1,index_2"
}

この例では、index1 と index2 のインデックスのみがバックアップされます。

スナップショット情報の照会

場合によっては、スナップショット情報を照会する必要があります。たとえば、日付を含む backup_2014_10_28 など、スナップショット名を覚えにくい場合などです。

スナップショットの情報を照会するには、リポジトリ名とスナップショット ID を含む GET リクエストを送信します。

GET _snapshot/my_backup/snapshot_2

レスポンスには、スナップショットの詳細情報が含まれます。

{
"snapshots": [
   {
      "snapshot": "snapshot_2",
      "indices": [
         ".marvel_2014_28_10",
         "index1",
         "index2"
      ],
      "state": "SUCCESS",
      "start_time": "2014-09-02T13:01:43.115Z",
      "start_time_in_millis": 1409662903115,
      "end_time": "2014-09-02T13:01:43.439Z",
      "end_time_in_millis": 1409662903439,
      "duration_in_millis": 324,
      "failures": [],
      "shards": {
         "total": 10,
         "failed": 0,
         "successful": 10
      }
   }
]
}

操作内のスナップショット ID を _all に置き換えると、リポジトリ内のすべてのスナップショットが照会されます。

GET _snapshot/my_backup/_all

スナップショットの削除

特定のスナップショットを削除するには、次のように、リポジトリ名とスナップショット ID を指定し、DELETE リクエストを送信します。

DELETE _snapshot/my_backup/snapshot_2

重要

スナップショットを削除するには、delete 操作を使用する必要があります。手動など、他の方法でスナップショットを削除しないでください。スナップショットは他のバックアップファイルに関連付けられています。一部のファイルは、他のスナップショットでも使用されています。 delete 操作では、他のスナップショットでまだ使用されているファイルは削除されません。削除するスナップショットに関連付けられていて、なおかつ他のスナップショットで使用されていないファイルのみが削除されます。
スナップショットを手動で削除すると、スナップショットに関連付けられているすべてのファイルを誤って削除する可能性があります。これにより、データが失われる可能性があります。

スナップショットの進行状況のモニタリング

wait_for_completion パラメーターは、スナップショットプロセスの進行状況をモニタリングするための最も簡単な方法です。ただし、このパラメーターは、中規模の Elasticsearch クラスター向けに実行されているスナップショットプロセスには適していません。スナップショットの詳細情報を照会するには、次の操作を呼び出します。

スナップショット ID を指定して、GET リクエストを送信します。
```
GET _snapshot/my_backup/snapshot_3
```
この操作を呼び出したときに Elasticsearch でスナップショットを作成中の場合、スナップショット作成プロセスの開始時間や期間など、進行状況が返されます。

重要スナップショットの進行状況のモニタリング操作は、スナップショット作成操作と同じスレッドプールを共有します。したがって、大きなシャードのスナップショットを作成中の場合、スナップショットの進行状況のモニタリング操作は、スナップショット作成操作がスレッドプールのリソースをリリースするまで待機する必要があります。

スナップショットのステータスを照会するには、_status 操作を呼び出します。

{
"snapshots": [
   {
      "snapshot": "snapshot_3",
      "repository": "my_backup",
      "state": "IN_PROGRESS", <1>
      "shards_stats": {
         "initializing": 0,
         "started": 1, <2>
         "finalizing": 0,
         "done": 4,
         "failed": 0,
         "total": 5
      },
      "stats": {
         "number_of_files": 5,
         "processed_files": 5,
         "total_size_in_bytes": 1792,
         "processed_size_in_bytes": 1792,
         "start_time_in_millis": 1409663054859,
         "time_in_millis": 64
      },
      "indices": {
         "index_3": {
            "shards_stats": {
               "initializing": 0,
               "started": 0,
               "finalizing": 0,
               "done": 5,
               "failed": 0,
               "total": 5
            },
            "stats": {
               "number_of_files": 5,
               "processed_files": 5,
               "total_size_in_bytes": 1792,
               "processed_size_in_bytes": 1792,
               "start_time_in_millis": 1409663054859,
               "time_in_millis": 64
            },
            "shards": {
               "0": {
                  "stage": "DONE",
                  "stats": {
                     "number_of_files": 1,
                     "processed_files": 1,
                     "total_size_in_bytes": 514,
                     "processed_size_in_bytes": 514,
                     "start_time_in_millis": 1409663054862,
                     "time_in_millis": 22
                  }
               },
               ...

<1>：スナップショットのステータス。スナップショットが進行中の場合、このフィールドに IN_PROGRESS と表示されます。
<2>：送信中のシャード数を示します。値 1 が返された場合、スナップショットのシャードの 1 つが送信中であることを示します。他の 4 つのシャードは、送信済みです。
shards_stats リストには、スナップショットのステータスと、各インデックスとシャードの統計情報が含まれます。これにより、スナップショットの進行状況の詳細を把握できます。シャードのステータスは、次のいずれかです。
- INITIALIZING：スナップショットを作成可能かどうか確認するため、クラスターのステータスを検証中です。通常、このプロセスは高速です。
- STARTED：データをリポジトリに送信中です。
- FINALIZING：データ送信プロセスを完了しました。スナップショットメタデータを送信中です。
- DONE：スナップショットを作成しました。
- FAILED：スナップショットプロセス中にエラーが発生しました。シャード、インデックス、またはスナップショットを完了できません。ログで詳細情報を確認できます。

スナップショットのキャンセル

スナップショットをキャンセルするには、スナップショットの進行中に次の操作を呼び出します。

DELETE _snapshot/my_backup/snapshot_3

この操作は、スナップショットプロセスを停止してから、進行中のスナップショットをリポジトリから削除します。

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

スナップショットからインデックスを復元するには、インデックスを復元する Elasticsearch インスタンスでリポジトリの作成操作を呼び出します。次のいずれかの方法で、スナップショットからインデックスを復元できます。

特定のスナップショットからインデックスを復元するには、次のように _restore パラメーターをスナップショット ID の後ろに追加し、操作を呼び出します。
```
POST _snapshot/my_backup/snapshot_1/_restore
```
デフォルトでは、この操作によりスナップショット内のすべてのインデックスが復元されます。たとえば、snapshot_1 スナップショットに 5 つのインデックスが含まれる場合、これらのインデックスはすべて Elasticsearch クラスターに復元されます。特定のインデックスのスナップショットの作成を参照して、復元するインデックスを指定することもできます。
特定のインデックスを復元し、インデックスの名前を変更します。既存のデータを上書きせず、元のデータを復元して内容を検証したり処理したりする場合、この方法を使用します。
```
POST /_snapshot/my_backup/snapshot_1/_restore
{
 "indices": "index_1", <1>
 "rename_pattern": "index_(.+)", <2>
 "rename_replacement": "restored_index_$1" <3>
}
```
この例では、インデックス index_1 が Elasticsearch クラスターに復元され、名前が restore_index_1 に変更されます。
- <1>：スナップショット内のインデックス Index_1 のみを復元します。
- <2>：復元対象のインデックスを検索し、指定されたパターンと照合します。
- <3>：一致するインデックスの名前を変更します。
復元プロセスの完了後に操作結果が返されるようにする場合、次のように wait_for_completion パラメーターを追加します。
```
POST _snapshot/my_backup/snapshot_1/_restore? wait_for_completion=true
```
_restore 操作は、すぐに結果が返されます。復元プロセスはバックグラウンドで実行されています。復元プロセスの完了後に操作結果が返されるようにする場合、wait_for_completion パラメーターを追加します。

復元操作のモニタリング

注リポジトリからデータを復元する処理では、Elasticsearch の既存の復元メカニズムが適用されます。リポジトリからシャードを復元する処理は、ノードからデータを復元する処理と同じです。

復元操作をモニタリングするには、recovery 操作を呼び出します。

復元中の特定のインデックスをモニタリングします。
```
GET restored_index_3/_recovery
```
recovery 操作は、クラスターに送信中のシャードのステータスを表示する一般的な操作です。
クラスター上のすべてのインデックスをモニタリングします。復元操作と関係のないシャードが含まれる場合があります。
```
GET /_recovery/
```
クラスターの状況によっては、大量の結果が返される場合があります。次の結果が返されます。
```
{
"restored_index_3" : {
 "shards" : [ {
   "id" : 0,
   "type" : "snapshot", <1>
   "stage" : "index",
   "primary" : true,
   "start_time" : "2014-02-24T12:15:59.716",
   "stop_time" : 0,
   "total_time_in_millis" : 175576,
   "source" : { <2>
     "repository" : "my_backup",
     "snapshot" : "snapshot_3",
     "index" : "restored_index_3"
   },
   "target" : {
     "id" : "ryqJ5lO5S4-lSFbGntkEkg",
     "hostname" : "my.fqdn",
     "ip" : "10.0.1.7",
     "name" : "my_es_node"
   },
   "index" : {
     "files" : {
       "total" : 73,
       "reused" : 0,
       "recovered" : 69,
       "percent" : "94.5%" <3>
     },
     "bytes" : {
       "total" : 79063092,
       "reused" : 0,
       "recovered" : 68891939,
       "percent" : "87.1%"
     },
     "total_time_in_millis" : 0
   },
   "translog" : {
     "recovered" : 0,
     "total_time_in_millis" : 0
   },
   "start" : {
     "check_index_time" : 0,
     "total_time_in_millis" : 0
   }
 } ]
}
}
```
- <1>：type フィールドは、復元操作のタイプです。値 snapshot は、シャードがスナップショットから復元中であることを示します。
- <2>：source フィールドは、ソースのスナップショットとリポジトリです。
- <3>：percent フィールドは、復元操作の進行状況です。値 94.5% は、シャードの 94.5％が復元されたことを示します。
出力には、復元中のすべてのインデックスと、これらのインデックス内のシャードが一覧表示されます。各シャードには、開始時間、停止時間、期間、復元の進行状況、送信バイト数に関する統計情報があります。

復元操作のキャンセル

復元操作をキャンセルするには、復元中のインデックスを削除する必要があります。復元操作は、シャード復元プロセスです。復元プロセスをキャンセルするには、DELETE 操作を呼び出してクラスターのステータスを変更します。

DELETE /restored_index_3

インデックス restore_index_3 を復元中の場合、復元プロセスが停止し、クラスターに復元済みのデータは削除されます。

詳細は、『Snapshot And Restore』をご参照ください。