ElasticsearchバックアップデータAWS 3
8556 ワード
ESクラスタバックアップデータS 3
クラスタ環境:
システムバージョン:centos 7.3インストール方式:yum ESバージョン環境:6.0.1
基本概念
Elasticsearch Snapshotを使用するには、指定したIndicesファイルを圧縮パッケージとしてS 3に捨てるのではなく、制御されている基本的な概念を明らかにする必要があります.
snapshot構造
Elasticsearchのsnapshotはそれ自身によって制御され、システム全体は以下のような下から上への制御構造を維持し、彼らは関係を含んでいる.
snapshot --> repository --> single snapshot --> indices
snapshot
ここでsnapshotを単独でリストするのは、Elasticsearchでsnapshotが独占的に働いているためで、彼はパイプのように、どのrepositoryも仕事中に彼を並べているが、indicesの書き込みを阻止していない.repositoryという倉庫はsnapshotバックアップのセットであるべきであり、ターゲットの選択とも考えられる.Elasticsearchシステムでは、自分の意思に応じて異なるRepositoryを設定することができます.
Single snapshot
これはRepositoryで私たちが行ったバックアップの内容を指しています.彼は今回のsnapshotのすべてのIndicesを含む集合のようです.
Indices
1つのsnapshotには、複数のIndicesファイルの内容を含めることができます.彼はsnapshotを実行するときにpatternで識別したり、一つ一つ指定したりすることができます.
S 3カード
ElasticsearchをS 3にバックアップさせるには、1つのプラグインS 3 Repository Pluginを個別にインストールする必要がある.
Repository
正常に実行snapshot以前には、まず自分のRepositoryを構築する必要があります.具体的な動作は、S 3 Repository Pluginを参照してS 3の構成動作を完了することができる.
AWSのアカウントパスワード制御は、システムのYAMLプロファイルに書く必要がなく、Repositoryを作成する設定に直接使用するとより柔軟になります.Repositoryを取得すると、アカウント情報の部分が自動的に遮断されます.
AWS IAM
これは少し複雑で、私たちがAWS IAMに詳しくないのかもしれません.Elastic公式に与えられたRecommanded S 3 Permissionsに従って直接配置すればよい.
ここで彼はAWS 3 Bucketのリスト権限を取得する必要があります.彼は自分のいくつかの制御ファイルを配置して入るので、比較操作も必要です.
異なるESシステムをAWS 3 Bucketにバックアップする必要がある場合は、Elasticsearchの制御ファイルが競合するため、異なるディレクトリに割り当てる必要があります.ここでは、このS 3 Permissionsの説明のうち、後のIAM構成の説明を参照すればよい.
snapshot操作
Repositoryが完了すると、直接実行できます.snapshotが操作されました.具体的な操作方法はSnapshot and Restoreセクションの説明を参照してください.指令比_searchは何倍簡単か分からない.
実行中に他のsnapshotが実行されている場合は、503:Service Unavailableのエラーメッセージが表示されます.これが上述したsnapshot実行の独占性であり,異なるrepository間でも並列にはできない.
S 3におけるファイルの役割
ElasticsearchはS 3でsnapshotを作成すると、snapshotの内容を管理するための補助ファイルを形成します.
最も腹立たしいのはElasticsearchが自分のIndicesでバックアップ情報を作成するのではなく、これらの情報をすべてS 3に入れたことだ.もちろん、よく知っていれば、このような利点は、他のESシステムが同じRepository構成でこれらのS 3の内容を読み取ることができることであることも理解される.
バックアップ構成手順
インストールが必要なプラグイン(esノードごとにインストールし、サービスを再起動することを推奨)
アクセスS 3のアカウントとパスワードの設定
key情報を削除します.
Amazon S 3リポジトリの例は以下の通りである.
パラメータ名詞の説明:
Type:倉庫タイプSettings:倉庫の追加情報Bucket:バケツ名
異なるESバージョンでサポートされているregionリファレンス:
Region: AWS Region Access_key:アクセスキーSecret_key:プライベートアクセスキー
上記のコマンドを使用して、倉庫(s 3-backup)を作成し、バケツ(esbackup)も作成し、{「acknowledged」:true}情報を返して作成に成功したことを証明します.
バックアップ・ウェアハウスが正常に作成されたかどうかを確認します.
作成したばかりのストレージ・ウェアハウスを表示するには、次の手順に従います.
すべてのエンクロージャを表示するには、次の手順に従います.
インデックスのバックアップ
ストレージ・ウェアハウスを作成してからバックアップを開始できます.1つの倉庫には複数のスナップショット(snapshots)を含めることができ、スナップショットはすべてのインデックスまたは一部のインデックスを格納することができ、もちろん個別のインデックスを格納することもできます.(スナップショットはopen状態のインデックスのみをバックアップし、close状態のバックアップはしません)
すべてのインデックスをバックアップ
curl -XPUT http://127.0.0.1:9200/_snapshot/backup/snapshot_all
上のコードは、実行中のopen状態のすべてのインデックスをbackupウェアハウスの次のsnapshot_にバックアップします.allのスナップショットです.上のapiはすぐに「accepted」:true}に戻り、バックアップ作業はバックグラウンドで実行されます.
apiを同期して実行したい場合はwaitを追加します.for_completionフラグ:
curl -XPUT http://127.0.0.1:9200/_snapshot/backup/snapshot_all?wait_for_completion=true
上記の方法では、バックアップが完全に完了してから戻りますが、スナップショットのデータ量が大きいと、時間がかかります.
部分インデックスのバックアップ
デフォルトはすべてのopenステータスのインデックスをバックアップします.インデックスの一部またはいずれかだけをバックアップしたい場合は、indicesパラメータを指定して完了できます.
curl -XPUT 'http://localhost:9200/_snapshot/backup/index-kjh-201712' -H 'Content-Type: application/json' -d '{ "indices": "index-kjh-2017.12"}'
indices:バックアップが必要なインデックスignore_unavailable:インデックスが存在しない場合は省略します.include_global_state:同じsnapshotを複数の異なるclusterに復元できるようにfalseに設定します.falseなのはglobal cluster stateをsnapshotにバックアップしたくないからです
スナップショット情報の表示
curl -XGET 'http://localhost:9200/_snapshot/backup/_all'?pretty
curl -XGET 'http://localhost:9200/_snapshot/backup/index-kjh-201712?'pretty
スナップショット情報を表示するには、GETリクエストを開始するだけでよい:詳細:
スナップショットの全体的な状況:
上記の情報は、各インスタンスと各インスタンスの統計データに深く入り込んでいます.これは、信じられない詳細なビュースナップショットがどのように進んでいるかを示します.フラグメントは、次のような方法で作成できます.
INITIALIZING:クラスタのフラグメントは、ステータスがスナップショットできるかどうかを確認します.これは通常非常に速いです.STARTED:データがリポジトリに転送されます.FINALIZING:データ転送完了;フラグメントは、スナップショットのメタデータを送信します.DONE:スナップショット完了.FAILED:スナップショット中にエラーの出所があり、このフラグメント/インデックス/スナップショットは完了できません.ログをチェックして、より多くの情報を取得します.
インデックスデータの復元:
curl -XPOST 'http://localhost:9200/_snapshot/backup/index-kjh-201712/_restore
リカバリのステータスを表示するには、次の手順に従います.
GET http://127.0.0.1:9200/_recovery/index-kjh-201712GET http://127.0.0.1:9200/_recovery/
スナップショットバケットを削除します.
curl -XDELETE localhost:9200/_snapshot/backup/index-kjh-201712?pretty
部分的なリカバリ:
デフォルトでは、1つ以上のインデックスがスナップショットに使用可能なスライスがない場合、リカバリ操作全体が失敗します.これらのインデックスは、部分的にtrueに復元することで復元できます.注意:この場合、正常なスライススナップショットのみが復元され、失われたスライスは空に再構築されます.
別のクラスタに復元
スナップショットに格納される情報は、特定のクラスタまたはクラスタ名に依存しません.従って、別のクラスタに復元することができる.これは、新しいクラスタにスナップショットに含まれるストレージメディアを登録し、リカバリプロセスを開始する必要があります.新しいクラスタは、同じサイズまたはトポロジを持つ必要はありませんが、新しいクラスタのバージョンは、作成したスナップショットのバージョンと同じまたはそれ以上です.
インデックスのコピーを減らして、より小さなクラスタに復元できます.
元のクラスタのインデックスがスライス割り当てフィルタリングを使用して特定のノードに割り当てられている場合、同じルールは新しいクラスタで強制的に実行されます.したがって、新しいクラスタにインデックス・リカバリの割当てプロパティの適切なノードが含まれていない場合、これらのインデックスがリカバリ・オペレーション中に割当て設定が変更されない限り、インデックスは正常に復元されません.
リカバリ操作もwait_をサポートfor_completionパラメータは、クライアントが操作が完了するまで停止します.これは、操作の完了に関する最も簡単な方法であることが知られている.
同じ時点で、1つのスナップショットまたはリカバリ操作のみが許可されます.
リカバリ操作は、標準的なスライスリカバリメカニズムを使用します.したがって、現在実行されているリカバリ操作は、リカバリ中のインデックスを削除することによって中止できます.この操作の結果、インデックスを削除したデータがクラスタから消去されます.
クラスタリカバリの手順は次のとおりです.
clusterA——s 3バックアップ環境を構成する－－clusterAはS 3バケツclusterBにバックアップを実行する－－s 3バックアップ環境を構成する－－clusterAバックアップバケツを指す－－clusterBはリカバリ操作を実行する
curl -XPOST 'http://localhost:9200/_snapshot/backup/index-kjh-201712/_restore
参照情報:
https://medium.com/@federicopanini/elasticsearch-backup-snapshot-and-restore-on-aws-s3-f1fc32fbca7f
https://www.elastic.co/guide/cn/elasticsearch/guide/current/backing-up-your-cluster.html#backing-up-your-cluster
クラスタ環境:
システムバージョン:centos 7.3インストール方式:yum ESバージョン環境:6.0.1
基本概念
Elasticsearch Snapshotを使用するには、指定したIndicesファイルを圧縮パッケージとしてS 3に捨てるのではなく、制御されている基本的な概念を明らかにする必要があります.
snapshot構造
Elasticsearchのsnapshotはそれ自身によって制御され、システム全体は以下のような下から上への制御構造を維持し、彼らは関係を含んでいる.
snapshot --> repository --> single snapshot --> indices
snapshot
ここでsnapshotを単独でリストするのは、Elasticsearchでsnapshotが独占的に働いているためで、彼はパイプのように、どのrepositoryも仕事中に彼を並べているが、indicesの書き込みを阻止していない.repositoryという倉庫はsnapshotバックアップのセットであるべきであり、ターゲットの選択とも考えられる.Elasticsearchシステムでは、自分の意思に応じて異なるRepositoryを設定することができます.
Single snapshot
これはRepositoryで私たちが行ったバックアップの内容を指しています.彼は今回のsnapshotのすべてのIndicesを含む集合のようです.
Indices
1つのsnapshotには、複数のIndicesファイルの内容を含めることができます.彼はsnapshotを実行するときにpatternで識別したり、一つ一つ指定したりすることができます.
S 3カード
ElasticsearchをS 3にバックアップさせるには、1つのプラグインS 3 Repository Pluginを個別にインストールする必要がある.
Repository
正常に実行snapshot以前には、まず自分のRepositoryを構築する必要があります.具体的な動作は、S 3 Repository Pluginを参照してS 3の構成動作を完了することができる.
AWSのアカウントパスワード制御は、システムのYAMLプロファイルに書く必要がなく、Repositoryを作成する設定に直接使用するとより柔軟になります.Repositoryを取得すると、アカウント情報の部分が自動的に遮断されます.
AWS IAM
これは少し複雑で、私たちがAWS IAMに詳しくないのかもしれません.Elastic公式に与えられたRecommanded S 3 Permissionsに従って直接配置すればよい.
Recommanded S3 Permissions:
https://www.elastic.co/guide/en/elasticsearch/plugins/current/repository-s3-repository.html#repository-s3-permissionsここで彼はAWS 3 Bucketのリスト権限を取得する必要があります.彼は自分のいくつかの制御ファイルを配置して入るので、比較操作も必要です.
異なるESシステムをAWS 3 Bucketにバックアップする必要がある場合は、Elasticsearchの制御ファイルが競合するため、異なるディレクトリに割り当てる必要があります.ここでは、このS 3 Permissionsの説明のうち、後のIAM構成の説明を参照すればよい.
snapshot操作
Repositoryが完了すると、直接実行できます.snapshotが操作されました.具体的な操作方法はSnapshot and Restoreセクションの説明を参照してください.指令比_searchは何倍簡単か分からない.
実行中に他のsnapshotが実行されている場合は、503:Service Unavailableのエラーメッセージが表示されます.これが上述したsnapshot実行の独占性であり,異なるrepository間でも並列にはできない.
S 3におけるファイルの役割
ElasticsearchはS 3でsnapshotを作成すると、snapshotの内容を管理するための補助ファイルを形成します.
最も腹立たしいのはElasticsearchが自分のIndicesでバックアップ情報を作成するのではなく、これらの情報をすべてS 3に入れたことだ.もちろん、よく知っていれば、このような利点は、他のESシステムが同じRepository構成でこれらのS 3の内容を読み取ることができることであることも理解される.
バックアップ構成手順
インストールが必要なプラグイン(esノードごとにインストールし、サービスを再起動することを推奨)
/opt/elasticsearch/bin/elasticsearch-plugin install repository-s3アクセスS 3のアカウントとパスワードの設定
#ACCESS-KEY
/opt/elasticsearch/bin/elasticsearch-keystore add s3.client.default.access_key
AKIAJLFDDDDDDDDDDDDD
#SECRET-KEY
/opt/elasticsearch/bin/elasticsearch-keystore add s3.client.default.secret_key
nHr5vFTxCBI6CbRgNGDAAAAAAAAAAkey情報を削除します.
/opt/elasticsearch/bin/elasticsearch-keystore remove s3.client.default.access_key
/opt/elasticsearch/bin/elasticsearch-keystore remove s3.client.default.secret_keyAmazon S 3リポジトリの例は以下の通りである.
curl -XPUT 'http://localhost:9200/_snapshot/backup' -H 'Content-Type: application/json' -d '{ "type": "s3", "settings": { "bucket": "pte-es-backup", } }' パラメータ名詞の説明:
Type:倉庫タイプSettings:倉庫の追加情報Bucket:バケツ名
異なるESバージョンでサポートされているregionリファレンス:
Region: AWS Region Access_key:アクセスキーSecret_key:プライベートアクセスキー
上記のコマンドを使用して、倉庫(s 3-backup)を作成し、バケツ(esbackup)も作成し、{「acknowledged」:true}情報を返して作成に成功したことを証明します.
バックアップ・ウェアハウスが正常に作成されたかどうかを確認します.
curl -XPOST http://localhost:9200/_snapshot/backup/_verify?pretty
{
"nodes" : {
"Uz61yrDjRXy-otyYiwLXtA" : {
"name" : "172.17.5.152"
},
"JgrZMa9CTRuoV1cezEeXuQ" : {
"name" : "172.17.5.153"
},
"z_BLa4u1SZWt5gA4oZRpOA" : {
"name" : "172.17.5.196"
}
}
}作成したばかりのストレージ・ウェアハウスを表示するには、次の手順に従います.
curl -XGET localhost:9200/_snapshot/backup?prettyすべてのエンクロージャを表示するには、次の手順に従います.
curl -XGET localhost:9200/_snapshot/_all?prettyインデックスのバックアップ
ストレージ・ウェアハウスを作成してからバックアップを開始できます.1つの倉庫には複数のスナップショット(snapshots)を含めることができ、スナップショットはすべてのインデックスまたは一部のインデックスを格納することができ、もちろん個別のインデックスを格納することもできます.(スナップショットはopen状態のインデックスのみをバックアップし、close状態のバックアップはしません)
すべてのインデックスをバックアップ
curl -XPUT http://127.0.0.1:9200/_snapshot/backup/snapshot_all
上のコードは、実行中のopen状態のすべてのインデックスをbackupウェアハウスの次のsnapshot_にバックアップします.allのスナップショットです.上のapiはすぐに「accepted」:true}に戻り、バックアップ作業はバックグラウンドで実行されます.
apiを同期して実行したい場合はwaitを追加します.for_completionフラグ:
curl -XPUT http://127.0.0.1:9200/_snapshot/backup/snapshot_all?wait_for_completion=true
上記の方法では、バックアップが完全に完了してから戻りますが、スナップショットのデータ量が大きいと、時間がかかります.
部分インデックスのバックアップ
デフォルトはすべてのopenステータスのインデックスをバックアップします.インデックスの一部またはいずれかだけをバックアップしたい場合は、indicesパラメータを指定して完了できます.
curl -XPUT 'http://localhost:9200/_snapshot/backup/index-kjh-201712' -H 'Content-Type: application/json' -d '{ "indices": "index-kjh-2017.12"}'
：
{
"indices": "products,index_1,index_2",
"ignore_unavailable": true,
"include_global_state": false
}indices:バックアップが必要なインデックスignore_unavailable:インデックスが存在しない場合は省略します.include_global_state:同じsnapshotを複数の異なるclusterに復元できるようにfalseに設定します.falseなのはglobal cluster stateをsnapshotにバックアップしたくないからです
スナップショット情報の表示
curl -XGET 'http://localhost:9200/_snapshot/backup/_all'?pretty
curl -XGET 'http://localhost:9200/_snapshot/backup/index-kjh-201712?'pretty
スナップショット情報を表示するには、GETリクエストを開始するだけでよい:詳細:
{
"snapshot" : "index-kjh-201712",
"uuid" : "mQPVTiYlR_Wc2ftR7OIrZw",
"version_id" : 6010099,
"version" : "6.1.0",
"indices" : [
"index-kjh-2017.12"
],
"state" : "SUCCESS", <============
"start_time" : "2018-01-04T11:15:04.974Z",
"start_time_in_millis" : 1515064504974,
"end_time" : "2018-01-04T11:15:07.658Z",
"end_time_in_millis" : 1515064507658,
"duration_in_millis" : 2684,
"failures" : [ ],
"shards" : {
"total" : 5,
"failed" : 0,
"successful" : 5
}
}
]
}
スナップショットの全体的な状況:
上記の情報は、各インスタンスと各インスタンスの統計データに深く入り込んでいます.これは、信じられない詳細なビュースナップショットがどのように進んでいるかを示します.フラグメントは、次のような方法で作成できます.
INITIALIZING:クラスタのフラグメントは、ステータスがスナップショットできるかどうかを確認します.これは通常非常に速いです.STARTED:データがリポジトリに転送されます.FINALIZING:データ転送完了;フラグメントは、スナップショットのメタデータを送信します.DONE:スナップショット完了.FAILED:スナップショット中にエラーの出所があり、このフラグメント/インデックス/スナップショットは完了できません.ログをチェックして、より多くの情報を取得します.
インデックスデータの復元:
curl -XPOST 'http://localhost:9200/_snapshot/backup/index-kjh-201712/_restore
リカバリのステータスを表示するには、次の手順に従います.
GET http://127.0.0.1:9200/_recovery/index-kjh-201712GET http://127.0.0.1:9200/_recovery/
スナップショットバケットを削除します.
curl -XDELETE localhost:9200/_snapshot/backup/index-kjh-201712?pretty
{
"acknowledged" : true
}部分的なリカバリ:
デフォルトでは、1つ以上のインデックスがスナップショットに使用可能なスライスがない場合、リカバリ操作全体が失敗します.これらのインデックスは、部分的にtrueに復元することで復元できます.注意:この場合、正常なスライススナップショットのみが復元され、失われたスライスは空に再構築されます.
別のクラスタに復元
スナップショットに格納される情報は、特定のクラスタまたはクラスタ名に依存しません.従って、別のクラスタに復元することができる.これは、新しいクラスタにスナップショットに含まれるストレージメディアを登録し、リカバリプロセスを開始する必要があります.新しいクラスタは、同じサイズまたはトポロジを持つ必要はありませんが、新しいクラスタのバージョンは、作成したスナップショットのバージョンと同じまたはそれ以上です.
インデックスのコピーを減らして、より小さなクラスタに復元できます.
元のクラスタのインデックスがスライス割り当てフィルタリングを使用して特定のノードに割り当てられている場合、同じルールは新しいクラスタで強制的に実行されます.したがって、新しいクラスタにインデックス・リカバリの割当てプロパティの適切なノードが含まれていない場合、これらのインデックスがリカバリ・オペレーション中に割当て設定が変更されない限り、インデックスは正常に復元されません.
リカバリ操作もwait_をサポートfor_completionパラメータは、クライアントが操作が完了するまで停止します.これは、操作の完了に関する最も簡単な方法であることが知られている.
同じ時点で、1つのスナップショットまたはリカバリ操作のみが許可されます.
リカバリ操作は、標準的なスライスリカバリメカニズムを使用します.したがって、現在実行されているリカバリ操作は、リカバリ中のインデックスを削除することによって中止できます.この操作の結果、インデックスを削除したデータがクラスタから消去されます.
クラスタリカバリの手順は次のとおりです.
clusterA——s 3バックアップ環境を構成する－－clusterAはS 3バケツclusterBにバックアップを実行する－－s 3バックアップ環境を構成する－－clusterAバックアップバケツを指す－－clusterBはリカバリ操作を実行する
curl -XPOST 'http://localhost:9200/_snapshot/backup/index-kjh-201712/_restore
参照情報:
https://medium.com/@federicopanini/elasticsearch-backup-snapshot-and-restore-on-aws-s3-f1fc32fbca7f
https://www.elastic.co/guide/cn/elasticsearch/guide/current/backing-up-your-cluster.html#backing-up-your-cluster