Elasticsearchクラスタのデータバックアップ
5730 ワード
バックアップ・クラスタは、ストレージ・データ・ソフトウェアの発展に伴い、従来のバックアップ・データがますます重要になります.Elasticsearchのreplicasは、実行時の高可用性を提供します.サービスが中断されない場合、不定時のノードのダウンタイムを許可します.しかし、Repalicasは災害性の失敗に対する保護を提供していません.そのため、クラスタをリアルタイムでバックアップする必要があります.必要に応じて、完全なコピーが必要です.クラスタをバックアップするには、snapshot APIを使用する必要があります.クラスタの現在のステータスとデータが共有ライブラリに保存されます.このバックアップのプロセスは「smart」です.最初のスナップショットは完全なデータコピーになり、後続のスナップショットは既存のスナップショットと新しいデータの間のインクリメンタルを保存します.時間が経つにつれて、データは徐々に追加され、削除されます.これは、転送されるデータが少ないため、後続のバックアップが大幅に加速することを意味します.この機能を使用するには、まずデータを保存するために倉庫を作成する必要があります.次のような選択可能な倉庫タイプがあります. Shared filesystem, such as a NAS Amazon S3 HDFS (Hadoop Distributed File System) Azure Cloud
倉庫を作成共有ファイルシステム倉庫を作成します:PUT_snapshot/my_backup { “type”: “fs”, “settings”: { “location”: “/mount/backups/my_backup” } }
これにより、マウントポイントに倉庫と必要なメタデータが作成されます.ノード、ネットワーク、および倉庫の場所に応じて、パフォーマンスプロファイルを設定することもできます.max_snapshot_bytes_per_secこのアイテムは、スナップショットデータが倉庫に入る流速を設定するために使用されます.デフォルトは20 M毎秒です.max_restore_bytes_per_sec倉庫からデータを復元する場合、ネットワークを不飽和にするために復元されたデータの流速を制御するために使用される.デフォルトは20 M毎秒です.
高速ネットワークがあり、追加のトラフィックを処理できると仮定すると、デフォルト値を増やすことができます.
POST _snapshot/my_backup/{"type":"fs","settings":{"location":"/mount/backups/my_backup","max_snapshot_bytes_per_sec":"50 mb","max_restore_bytes_per_sec":"50 mb"}注意:PUTの代わりにPOSTを使用すると、存在する設定が更新されます.次にsettingsを追加します.
すべてのインデックスをスナップ
倉庫には複数のスナップショットが含まれている可能性があります.各スナップショットには、特定の数のインデックス(たとえば、すべて、数、または1つ)が含まれます.倉庫を作成するときに、スナップショットのインデックスを指定し、スナップショットの名前を指定する必要があります.
最も基本的なスナップショットコマンド:PUT_snapshot/my_backup/snapshot_1
すべてのインデックスをmy_にバックアップしますbackupライブラリの名前はsnapshot_です1のスナップショットです.このリクエストはすぐに返され、スナップショットプロセスはバックグラウンドで実行されます.
アドバイス:通常、スナップショットプロセスをバックグラウンドプロセスとして使用したいと思っていますが、たまにスクリプトで完了を待つこともできます.waitを増やすことができます.for_completionフラグ.PUT _snapshot/my_backup/snapshot_1?wait_for_completion=true今回のリクエストは、スナップショットが完了するまでブロックされるため、ビッグデータ量のスナップショットが長時間待つ可能性があります.
スナップショット固有インデックス
デフォルトの動作は、すべてのオープンインデックスをスナップショットします.しかし、あなたはMarvelを使って、スナップショットをしたくないかもしれません.marvelの最後のインデックス、またはすべてのインデックスをバックアップするのに十分なスペースがありません.
この場合、クラスタをスナップショットするときに、特定のインデックス名を指定できます.PUT _snapshot/my_backup/snapshot_2{"indices":"index_1,index_2"}今回のスナップショットはindex_1,index_2 2つのインデックス.
スナップショットに関する情報を表示倉庫に蓄積すると、特にスナップショット名の名前が時間の限界に基づいている場合(backup_2014_10_28など)、特定のスナップショットに関する情報を忘れてしまうかもしれません.
個々のスナップショットの情報を取得するには、GETリクエストで特定の倉庫名とスナップショット名を付けるだけです.GET _snapshot/my_backup/snapshot_2スナップショットに関する簡単な情報が返されます.{ “snapshots”: [ { “snapshot”: “snapshot_1”, “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}}倉庫内のすべてのスナップショットを取得するには_allはスナップショット名の代わりに使用されます.GET _snapshot/my_backup/_all
最後に、スナップショットを削除するには、コマンドを使用して古いスナップショットを削除する必要があります.DELETEのHTTPリクエストにより、対応するウェアハウス/スナップショット名が呼び出されます.DELETE _snapshot/my_backup/snapshot_2 APIを使用してスナップショットを削除することは、他のメカニズムがないため、極めて重要である.スナップショットはインクリメンタルで、多くのスナップショットが古い部分に依存する可能性があります.Delete APIは、それらのデータが最近のスナップショットで使用されていることを理解し、古い部分を削除することができる.ただし、ファイルを手動で削除すると、使用しているデータが削除されたため、バックアップを中断するリスクがあります.
スナップショット処理の監視Wait_for_completionフラグは基本的なモニタリング情報を提供するが,スナップショットやクラスタのリカバリには明らかに不十分である.
他の2つのAPIは、スナップショットのステータスに関するより多くの情報を提供します.まず、私たちが前に情報を取得したように、GETリクエストを通じてスナップショットIDを取得する必要があります.GET _snapshot/my_backup/snapshot_3リクエスト時にスナップショットプロセスが実行されている場合は、スナップショットがいつ開始されたか、どのくらい実行されたかなどの情報が表示されます.このAPIとスナップショットは同じスレッドプールを使用していることに注意してください.スナップショットが大きいスライスの場合、スレッドプールのリソースが競合するため、更新時間が長くなる可能性があります.
より良いAPI選択:GET_snapshot/my_backup/snapshot_3/_status _statusはすぐに戻り、より多くの統計を与えることができます.
{ “snapshots”: [ { “snapshot”: “snapshot_3”, “repository”: “my_backup”, “state”: “IN_PROGRESS”, “shards_stats”: { “initializing”: 0, “started”: 1, “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":14096305862,"time_in_millis":22},...スナップショットがゆっくりと動作しており、その状態が表示されるように:IN_PROGRESSこのスナップショットには、1つのスライスがデータを転送しています(他の4つは完了しています).
レスポンスには、スナップショットの全体的なステータスが含まれます.また、各インデックスと各スライスの統計にドリルダウンすることもできます.これは信じられない詳細なビューを提供します.スナップショットの進捗状況はどうですか.各スライスは、異なる完了状態にあることができる.INITIALIZINGスライスはクラスタ状態をチェックしてスナップショットができるかどうかを確認しています.これは通常、STARTEDデータがリポジトリに転送されているFINALIZINGデータの転送が完了しています.スライスはスナップショットメタデータDONEスナップショットを送信しています.FAILEDスナップショットを完了する過程でエラーが発生しました.このスライス/インデックス/スナップショットは完了していません.ログをチェックすることで、より多くの情報を得ることができます.
最後にスナップショットをキャンセルするには、スナップショットをキャンセルするかリストアする必要があります.これは長期にわたって実行されるプロセスであるため、実行中にエラーが発生する可能性があります.そのため、貴重なリソースを占有したくないため、問題を解決するのに長い時間がかかる可能性があります.
スナップショットをキャンセルし、実行中にスナップショットを削除します.DELETE _snapshot/my_backup/snapshot_3スナップショットの処理を一時停止し、未完了のスナップショットを倉庫から削除します.
原文公式文書を参照:https://www.elastic.co/guide/en/elasticsearch/guide/current/backing-up-your-cluster.html
倉庫を作成共有ファイルシステム倉庫を作成します:PUT_snapshot/my_backup { “type”: “fs”, “settings”: { “location”: “/mount/backups/my_backup” } }
， my_backup
，
： 。
これにより、マウントポイントに倉庫と必要なメタデータが作成されます.ノード、ネットワーク、および倉庫の場所に応じて、パフォーマンスプロファイルを設定することもできます.max_snapshot_bytes_per_secこのアイテムは、スナップショットデータが倉庫に入る流速を設定するために使用されます.デフォルトは20 M毎秒です.max_restore_bytes_per_sec倉庫からデータを復元する場合、ネットワークを不飽和にするために復元されたデータの流速を制御するために使用される.デフォルトは20 M毎秒です.
高速ネットワークがあり、追加のトラフィックを処理できると仮定すると、デフォルト値を増やすことができます.
POST _snapshot/my_backup/{"type":"fs","settings":{"location":"/mount/backups/my_backup","max_snapshot_bytes_per_sec":"50 mb","max_restore_bytes_per_sec":"50 mb"}注意:PUTの代わりにPOSTを使用すると、存在する設定が更新されます.次にsettingsを追加します.
すべてのインデックスをスナップ
倉庫には複数のスナップショットが含まれている可能性があります.各スナップショットには、特定の数のインデックス(たとえば、すべて、数、または1つ)が含まれます.倉庫を作成するときに、スナップショットのインデックスを指定し、スナップショットの名前を指定する必要があります.
最も基本的なスナップショットコマンド:PUT_snapshot/my_backup/snapshot_1
すべてのインデックスをmy_にバックアップしますbackupライブラリの名前はsnapshot_です1のスナップショットです.このリクエストはすぐに返され、スナップショットプロセスはバックグラウンドで実行されます.
アドバイス:通常、スナップショットプロセスをバックグラウンドプロセスとして使用したいと思っていますが、たまにスクリプトで完了を待つこともできます.waitを増やすことができます.for_completionフラグ.PUT _snapshot/my_backup/snapshot_1?wait_for_completion=true今回のリクエストは、スナップショットが完了するまでブロックされるため、ビッグデータ量のスナップショットが長時間待つ可能性があります.
スナップショット固有インデックス
デフォルトの動作は、すべてのオープンインデックスをスナップショットします.しかし、あなたはMarvelを使って、スナップショットをしたくないかもしれません.marvelの最後のインデックス、またはすべてのインデックスをバックアップするのに十分なスペースがありません.
この場合、クラスタをスナップショットするときに、特定のインデックス名を指定できます.PUT _snapshot/my_backup/snapshot_2{"indices":"index_1,index_2"}今回のスナップショットはindex_1,index_2 2つのインデックス.
スナップショットに関する情報を表示倉庫に蓄積すると、特にスナップショット名の名前が時間の限界に基づいている場合(backup_2014_10_28など)、特定のスナップショットに関する情報を忘れてしまうかもしれません.
個々のスナップショットの情報を取得するには、GETリクエストで特定の倉庫名とスナップショット名を付けるだけです.GET _snapshot/my_backup/snapshot_2スナップショットに関する簡単な情報が返されます.{ “snapshots”: [ { “snapshot”: “snapshot_1”, “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}}倉庫内のすべてのスナップショットを取得するには_allはスナップショット名の代わりに使用されます.GET _snapshot/my_backup/_all
最後に、スナップショットを削除するには、コマンドを使用して古いスナップショットを削除する必要があります.DELETEのHTTPリクエストにより、対応するウェアハウス/スナップショット名が呼び出されます.DELETE _snapshot/my_backup/snapshot_2 APIを使用してスナップショットを削除することは、他のメカニズムがないため、極めて重要である.スナップショットはインクリメンタルで、多くのスナップショットが古い部分に依存する可能性があります.Delete APIは、それらのデータが最近のスナップショットで使用されていることを理解し、古い部分を削除することができる.ただし、ファイルを手動で削除すると、使用しているデータが削除されたため、バックアップを中断するリスクがあります.
スナップショット処理の監視Wait_for_completionフラグは基本的なモニタリング情報を提供するが,スナップショットやクラスタのリカバリには明らかに不十分である.
他の2つのAPIは、スナップショットのステータスに関するより多くの情報を提供します.まず、私たちが前に情報を取得したように、GETリクエストを通じてスナップショットIDを取得する必要があります.GET _snapshot/my_backup/snapshot_3リクエスト時にスナップショットプロセスが実行されている場合は、スナップショットがいつ開始されたか、どのくらい実行されたかなどの情報が表示されます.このAPIとスナップショットは同じスレッドプールを使用していることに注意してください.スナップショットが大きいスライスの場合、スレッドプールのリソースが競合するため、更新時間が長くなる可能性があります.
より良いAPI選択:GET_snapshot/my_backup/snapshot_3/_status _statusはすぐに戻り、より多くの統計を与えることができます.
{ “snapshots”: [ { “snapshot”: “snapshot_3”, “repository”: “my_backup”, “state”: “IN_PROGRESS”, “shards_stats”: { “initializing”: 0, “started”: 1, “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":14096305862,"time_in_millis":22},...スナップショットがゆっくりと動作しており、その状態が表示されるように:IN_PROGRESSこのスナップショットには、1つのスライスがデータを転送しています(他の4つは完了しています).
レスポンスには、スナップショットの全体的なステータスが含まれます.また、各インデックスと各スライスの統計にドリルダウンすることもできます.これは信じられない詳細なビューを提供します.スナップショットの進捗状況はどうですか.各スライスは、異なる完了状態にあることができる.INITIALIZINGスライスはクラスタ状態をチェックしてスナップショットができるかどうかを確認しています.これは通常、STARTEDデータがリポジトリに転送されているFINALIZINGデータの転送が完了しています.スライスはスナップショットメタデータDONEスナップショットを送信しています.FAILEDスナップショットを完了する過程でエラーが発生しました.このスライス/インデックス/スナップショットは完了していません.ログをチェックすることで、より多くの情報を得ることができます.
最後にスナップショットをキャンセルするには、スナップショットをキャンセルするかリストアする必要があります.これは長期にわたって実行されるプロセスであるため、実行中にエラーが発生する可能性があります.そのため、貴重なリソースを占有したくないため、問題を解決するのに長い時間がかかる可能性があります.
スナップショットをキャンセルし、実行中にスナップショットを削除します.DELETE _snapshot/my_backup/snapshot_3スナップショットの処理を一時停止し、未完了のスナップショットを倉庫から削除します.
原文公式文書を参照:https://www.elastic.co/guide/en/elasticsearch/guide/current/backing-up-your-cluster.html