ElasticSearchメンテナンス-バックアップとリカバリ

4043 ワード

ElasticSearch

本編では、ElasticSearchの生産における運用メンテナンス-バックアップとリカバリについて説明します.
バックアップ:
最初のステップ、倉庫の作成
実はバックアップストレージの目的倉庫を作成し、FileSystem、Amazon S 3、Azure Cloud、HDFSをサポートする.
作成コマンドは次のとおりです.

PUT _snapshot/my_backup
{
  "type": "fs",
  "settings": {
    "location": "/home/docker/back"
  }
}

まず、コマンドはhttpプロトコルによって行われるので、ESのバックアップはES実行時に行われます.単純なシステムレベルのファイルコピーではありません.バックアップ前にESを起動してください.
コマンドの実行後にエラーが発生しました:

"reason": "[my_backup] location [/mount/backups/my_backup] doesn't match any of the locations specified by path.repo because this setting is empty"

資料を探してバックアップするlocation fsはelasticsearchで必要であることを発見した.ymlで構成し、行を1行増やします.

path.repo: ["/home/docker/back"]

構成を変更してESを再起動し、上のコマンドを実行します.
ここでSettingsにはいくつかのデフォルトパラメータがあります.
compress、圧縮するかどうか、デフォルトはYesです.
max_restore_bytes_per_sec,ノード回復速度.デフォルトは40 mb/sです.
max_snapshot_bytes_per_sec、各ノードのスナップショットレート.デフォルトは40 mb/sです.
デフォルトのパラメータは、次のコマンドで変更できます.

POST _snapshot/my_backup/
{
  "type": "fs",
  "settings": {
    "compress": true,
    "location": "/home/docker/back",
    "max_snapshot_bytes_per_sec" : "50mb",
    "max_restore_bytes_per_sec" : "50mb"
  }
}

倉庫の作成が終わったら、locationの位置に行ってみましょう.中はまだ空いています.

ステップ2、インデックスのバックアップ
本質は、さっきの倉庫でスナップショットを作成することです.スナップショットは1つ以上のインデックスを指定してバックアップすることができます.デフォルトはすべてのインデックスで、同じ倉庫で複数のスナップショットを作成することができます.
バックアッププロセスは同期と非同期に分けられ、デフォルトは非同期で、バックアップはバックグラウンドで実行され、wait_for_completion=trueパラメータは同期に設定されます.
すべてのインデックスを非同期でバックアップ

PUT _snapshot/my_backup/snapshot_all

部分インデックスの同期バックアップ

PUT _snapshot/my_backup/snapshot_entity?wait_for_completion=true
{
  "indices": "index_entity"
}

このステップを実行すると、locationの下で本当にスナップショットファイルが追加されます.

ステップ3では、バックアップ情報を表示します.

GET _snapshot/my_backup/snapshot_all

次のように返されます.

{
  "snapshots": [
    {
      "snapshot": "snapshot_all",
      "uuid": "4LWRo_WbR5mzFlZ6ozuDrg",
      "version_id": 5060199,
      "version": "5.6.1",
      "indices": [
        "my_index",
        "applog",
        "index_entity",
        "index1",
        ".kibana"
      ],
      "state": "SUCCESS",
      "start_time": "2017-11-03T02:34:17.832Z",
      "start_time_in_millis": 1509676457832,
      "end_time": "2017-11-03T02:34:18.537Z",
      "end_time_in_millis": 1509676458537,
      "duration_in_millis": 705,
      "failures": [],
      "shards": {
        "total": 21,
        "failed": 0,
        "successful": 21
      }
    }
  ]
}

実は、このコマンドは、上記の同期バックアップの場合と同じです.このコマンドは、主に非同期バックアップの実行結果を表示するために使用されます.

第四部、廃棄バックアップスナップショットの削除

DELETE _snapshot/my_backup/snapshot_applog

リカバリ:
リカバリコマンドは簡単です.スナップショットを選択して実行します.restoreでもデフォルト非同期で実行できますwait_for_completion=trueは、次のように同期実行に変更できます.

POST _snapshot/my_backup/snapshot_entity/_restore

しかし、実行後のエラーは以下の通りです.

reason": "[my_backup:snapshot_entity/hxNnq8CsRAm3Yi8IvD0ZeA] cannot restore index [index_entity] because it's open"

さらに資料を探します.インデックスを送信するには、返信されたときに閉じる必要があります.そうしないと、インデックスの書き込み操作がリカバリに影響し、インデックスを閉じます.

POST index_entity/_close

リカバリコマンドの再実行

POST _snapshot/my_backup/snapshot_entity/_restore

成功しました.復元したらインデックスを開くのを忘れないでください

POST index_entity/_open

大きなスナップショットからインデックスの一部のみをリカバリする場合は、次のコマンドを実行します.

POST _snapshot/my_backup/snapshot_all/_restore
{
  "indices": "index_entity"
}

Gitlabサーバの移行

Bitnami Redmineバックアップ方法