Elasticsearch のスナップショット機能を使用して、クラスターのインデックスデータを Alibaba Cloud Object Storage Service (OSS) にバックアップし、必要に応じてリストアできます。手動スナップショットは、データ移行、ポイントインタイムリカバリ、開発およびテスト環境のセットアップ、高リスク操作前のバックアップ作成に最適です。自動スナップショットと比較して、手動スナップショットは範囲とタイミングにおいてより柔軟性がありますが、そのライフサイクルを管理する必要があります。
データバックアップとリストアは、elasticsearch-repository-oss プラグインに依存します。このプラグインは、Alibaba Cloud Elasticsearch インスタンスにデフォルトでインストールされており、アンインストールすることはできません。詳細については、「elasticsearch-repository-oss」をご参照ください。
スナップショットはインデックスデータのみを保存します。.monitoringまたは.security_auditプレフィックスを持つインデックスなどのモニタリングデータ、メタデータ、トランスログ、インスタンス構成、ソフトウェアパッケージ、プラグイン、ログは保存されません。このトピックのすべてのコマンドは、Kibana コンソールの Dev Tools で実行できます。詳細については、「Kibana コンソールへのログイン」をご参照ください。
スナップショットリポジトリの作成
スナップショットリポジトリは、スナップショットを保存するための論理コンテナです。リポジトリを作成する前に、ご利用の Elasticsearch インスタンスと同じリージョンに OSS バケットが必要です。標準ストレージクラスの使用を推奨します。手順については、「バケットの作成」をご参照ください。RAM ユーザーには AliyunOSSFullAccess ポリシーが必要です。手順については、「RAM ユーザーへの権限付与」をご参照ください。
次の例では、my_backup という名前のリポジトリを作成します。
Alibaba Cloud クラスター
PUT _snapshot/my_backup/
{
"type": "oss",
"settings": {
"endpoint": "http://oss-cn-hangzhou-internal.aliyuncs.com",
"access_key_id": "xxxx",
"secret_access_key": "xxxxxx",
"bucket": "xxxxxx",
"compress": true,
"chunk_size": "500mb",
"base_path": "snapshot/"
}
}セルフマネージド 8.x クラスター
セルフマネージドクラスターの場合、まず elasticsearch-repository-oss プラグインをインストールする必要があります。詳細については、「elasticsearch-repository-oss plugin」をご参照ください。セルフマネージドクラスターを構成する場合、パラメーター名の前に oss.client. を付ける必要があります。
PUT /_snapshot/my_backup
{
"type": "oss",
"settings": {
"oss.client.endpoint": "oss-cn-shanghai.aliyuncs.com",
"oss.client.access_key_id": "xxx",
"oss.client.secret_access_key": "xxx",
"oss.client.bucket": "xxxxxx",
"oss.client.base_path":"snapshot/",
"oss.client.compress": true
}
}パラメーター
パラメーター | 説明 |
endpoint | OSS バケットの内部エンドポイント。詳細については、「リージョンとエンドポイント」をご参照ください。 |
access_key_id | RAM ユーザーの AccessKey ID。手順については、「AccessKey ペアの取得」をご参照ください。 |
secret_access_key | RAM ユーザーの AccessKey Secret。手順については、「AccessKey ペアの取得」をご参照ください。 |
bucket | 既存の OSS バケットの名前。 |
compress | インデックスマッピングや設定などのスナップショットメタデータファイルを圧縮するかどうかを指定します。データファイルは影響を受けません。デフォルトは |
chunk_size | 各データチャンクのサイズ制限。このサイズより大きいデータは、OSS にアップロードされる前に複数のチャンクに分割されます。 |
base_path | バケット内のリポジトリのベースパス。デフォルトはバケットルートです。異なるクラスターや環境からのスナップショットを分離するために、 |
リポジトリ接続性の検証
POST _snapshot/my_backup/_verifyリクエストが成功すると、リポジトリに正常に接続されたすべてのノードのリストが返されます。エラーが発生した場合は、エンドポイント、バケット名、および RAM ユーザーの権限を確認してください。
リポジトリ情報の取得
# Get information about all repositories
GET _snapshot
# Get information about a specific repository
GET _snapshot/my_backupスナップショットの作成
全インデックスのスナップショット
PUT _snapshot/my_backup/snapshot_1このコマンドは、すべてのオープンインデックスに対して snapshot_1 という名前のスナップショットを作成します。コマンドはすぐに返され、スナップショットはバックグラウンドで実行されます。バックアップが完了するまで呼び出しをブロックするには、wait_for_completion=true パラメーターを追加します。
PUT _snapshot/my_backup/snapshot_1?wait_for_completion=trueリポジトリには複数のスナップショットを含めることができます。最初のスナップショットは完全バックアップです。以降のスナップショットは、前回のスナップショット以降に変更されたデータのみを保存する増分バックアップであり、バックアップ時間を短縮します。
特定のインデックスのスナップショット
PUT _snapshot/my_backup/snapshot_2
{
"indices": "index_1,index_2",
"ignore_unavailable": true,
"include_global_state": false
}パラメーター | 説明 |
indices | バックアップするインデックスを指定します。複数のインデックスはコンマで区切ります。 |
ignore_unavailable |
|
include_global_state |
|
スナップショット情報
# View all snapshots
GET _snapshot/my_backup/_all
# View a specific snapshot
GET _snapshot/my_backup/snapshot_1
# View the detailed status of a snapshot, including statistics for each index and shard
GET _snapshot/my_backup/snapshot_1/_statusスナップショットの削除
DELETE _snapshot/my_backup/snapshot_1スナップショットが進行中の場合、このコマンドはプロセスを停止し、作成された部分的なデータを削除します。
OSS コンソールまたは他のツールを使用してスナップショットファイルを直接削除しないでください。この操作は増分バックアップチェーンを破壊し、以降のすべてのスナップショットを破損させ、回復不能にする可能性があります。
スナップショットからのリストア
データをリストアする前に、次の点に注意してください。
ピリオド (
.) で始まるシステムインデックスは、Kibana へのアクセスが失敗する可能性があるため、リストアしないことを推奨します。ターゲットクラスターに同じ名前のインデックスが既に存在する場合、既存のインデックスをまず閉じるか削除する必要があります。そうしないと、リストアは失敗します。
クロスリージョンリストアを実行するには、まず OSS 内のスナップショットデータをターゲットリージョンに移行し、その後ターゲットクラスターにリストアする必要があります。OSS バケット間のデータ移行については、「移行の実装」をご参照ください。
ターゲットクラスターでのリポジトリ作成
データをリストアする前に、バックアップの OSS ロケーションを指すリポジトリをターゲットクラスターに作成する必要があります。パラメーター構成については、「スナップショットリポジトリの作成」をご参照ください。
PUT _snapshot/my_backup_restore/
{
"type": "oss",
"settings": {
"endpoint": "http://oss-cn-hangzhou-internal.aliyuncs.com",
"access_key_id": "xxxx",
"secret_access_key": "xxxxxx",
"bucket": "xxxxxx",
"compress": true,
"chunk_size": "500mb",
"base_path": "snapshot/"
}
}特定のインデックスのリストア
特定のインデックスをリストアし、既存のインデックスとの競合を避けるために名前を変更します。
POST /_snapshot/my_backup_restore/snapshot_1/_restore
{
"indices": "index_1",
"rename_pattern": "index_(.+)",
"rename_replacement": "restored_index_$1"
}パラメーター | 説明 |
indices | スナップショット内の他のすべてのインデックスを無視して、リストアするインデックスを指定します。 |
rename_pattern | リストアするインデックス名に一致する正規表現パターン。 |
rename_replacement | 新しいインデックス名の置換パターン。正規表現のキャプチャグループ参照をサポートします。 |
非システムインデックスのリストア
POST _snapshot/my_backup_restore/snapshot_1/_restore
{"indices": "*,-.monitoring*,-.security*,-.kibana*,-.internal.alerts*,-.alerts*","ignore_unavailable": true}上記の除外パターンは、一般的なシステムインデックスをカバーしています。クラスターのバージョンによっては、.ds-ilm-history-*や.slo-*などの他のシステムインデックスが存在する場合があります。クラスター内のシステムインデックスに基づいて除外リストを調整してください。8.x クラスターの場合、通常、-.ds*をリストに追加するなどして、データストリームバッキングインデックスも除外する必要があります。
全インデックスのリストア
POST _snapshot/my_backup_restore/snapshot_1/_restore_restore API はすぐに返され、リストアはバックグラウンドで実行されます。リストアが完了するまで呼び出しをブロックするには、wait_for_completion=true パラメーターを追加します。
POST _snapshot/my_backup_restore/snapshot_1/_restore?wait_for_completion=trueIndexing Service へのリストア
スナップショットを Indexing Service インスタンスにリストアする場合、互換性のないインデックス設定を無視するには、ignore_index_settings パラメーターを使用します。
POST /_snapshot/my_backup_restore/snapshot_1/_restore
{
"indices": "index_1",
"ignore_index_settings": [
"index.apack.cube.following_index"
]
}スナップショットリストアのステータス
_recovery API を使用して、リストアのステータスと進行状況を監視します。
# Check the restoration status of a specific index
GET restored_index_1/_recovery
# Check restoration status for all indexes (may include unrelated shards)
GET /_recovery/出力の主要フィールド:
フィールド | 説明 |
type | リカバリタイプ。 |
source | ソースリポジトリとスナップショット。 |
percent | リストアの進行状況 (パーセンテージ)。 |
リストアのキャンセル
リストアをキャンセルするには、リストア中のインデックスを削除します。
DELETE /restored_index_3このコマンドはリストアを停止し、そのインデックスについて既にクラスターにリストアされたすべてのデータを削除します。