スナップショットからシャーディングされたクラスターを復元
- Cloud Managerへのプログラムによるアクセスのための OAuth 2.0認証はプレビュー機能として利用できます。
- 機能および関連するドキュメントは、プレビュー期間中にいつでも変更される可能性があります。 OAuth2.0 認証を使用するには、 Cloud Manager Public APIへのリクエストで使用する サービス アカウント を作成します。
スナップショットからクラスターを復元すると、Cloud Manager は選択した復元ポイントの復元ファイルを提供します。
復元プロセスの詳細については、「復元の概要 」を参照してください。
Considerations
BinDataBSONサブタイプへの変更を確認する
BSON 仕様 BSON バイナリ データ型（BinData ）のデフォルトのサブタイプを2 から0 に変更しました。スナップショットに保存される一部のバイナリ データは、 BinDataサブタイプ2である場合があります。 バックアップは、 BinDataサブタイプ2のスナップショット データを自動的に検出し、 BinDataサブタイプ0に変換します。 アプリケーション コードでBinDataサブタイプ2が予測されている場合は、アプリケーション コードを更新してBinDataサブタイプ0で動作するようにする必要があります。
次で指定された設定を使用して復元します: restoreInfo.txt
バックアップ復元ファイルには、 restoreInfo.txtという名前のメタデータ ファイルが含まれています。 このファイルは、スナップショットの取得時にデータベースが使用したオプションをキャプチャします。 データベースは、復元した後、リストされているオプションで実行する必要があります。 このファイルには、次のものが含まれています。
groupName
ReplicaSetName
クラスター ID （該当する場合）
スナップショット タイムスタンプ（UTC のタイムスタンプ）
タイムスタンプの復元（UTC の BSON タイムスタンプとして）
最後に適用された oplog （UTC の BSON タイムスタンプとして）
MongoDB バージョン
ストレージ エンジンの種類
mongodスナップショットの取得時にデータベースで使用されたスタートアップオプション
エージェントがバランサーを停止できない場合のスナップショット
Cloud Manager は、バランサーが有効になっている間に取得されたクラスター スナップショットの横に警告を表示します。 このようなスナップショットから復元すると、データが失われる、または孤立するリスクがあります。 詳細については、「エージェントがバランサーを停止できない場合のスナップショット 」を参照してください。
バックアップに関する考慮事項
すべての FCVデータベースは、適切なバックアップに関する考慮事項を満たしている必要があります。
暗号化に関する考慮事項
復元中の MongoDB へのクライアントリクエストの無効化
復元中に MongoDB 配置がクライアント リクエストを受信しないことを確認する必要があります。 次のいずれかを行う必要があります。
新しいホスト名を持つ新しいシステムに復元し、新しい配置が実行中以降にアプリケーション コードを再構成する。または、
データの復元中に MongoDB 配置がクライアント リクエストを受信しないことを確認します。
スナップショットの復元
Cloud Manager がスナップショットを自動的に復元するようにするには、次の手順に従います。
MongoDB Cloud MongoDB Cloud ManagerManagerで、プロジェクトのGo {0 ページにGoします。Continuous Backup
まだ表示されていない場合は、目的のプロジェクトを含む組織をナビゲーション バーの Organizations メニューで選択します。
まだ表示されていない場合は、ナビゲーション バーのProjectsメニューから目的のプロジェクトを選択します。
サイドバーの Continuous Backup をクリックします。
[継続的なバックアップ ]ページが表示されます。
復元ポイントを選択します。
バックアップを復元するポイントを選択します。
復元タイプ説明アクションSnapshot
復元する既存のスナップショットを選択します。
Point In Time
選択した時間までのすべての操作を含むカスタム スナップショットを作成します（選択した時間は含みません）。 デフォルトでは、 oplogストアは 24 時間のデータを保存します。
たとえば、
12:00を選択した場合、復元の最後の操作は11:59:59またはそれ以前のバージョンになります。重要: FCV 4.0では、最新のバックアップ再同期の前の時間をカバーするPIT復元は実行できません。 再同期を引き起こす条件については、「バックアップの再同期 」を参照してください。 この注は FCV 4.2以降には適用されません。
DateとTimeを選択します。
Oplog Timestamp
入力されたoplogのタイムスタンプまでのすべての操作を含むカスタム スナップショットを作成します。 oplogタイムスタンプには次の 2 つのフィールドが含まれています。
Timestamp
UNIXエポック からの経過秒数におけるタイムスタンプ
Increment
その秒に適用される操作の順序を 32 ビット序数として表します。
oplog Timestamp と Increment を入力します。
レプリカセットで
local.oplog.rsに対してクエリを実行し、目的のタイムスタンプを見つけます。[Next] をクリックします。
を選択して、ファイルを別のクラスターに復元します。
[Choose Cluster to Restore to] をクリックします。
次のフィールドを入力します。
フィールドアクションProject
スナップショット を復元する プロジェクト を選択します。
Cluster to Restore to
スナップショットを復元するクラスターを選択します。
Cloud Manager は、ターゲットのシャーディングされたクラスターを管理する必要があります。
警告:オートメーションにより、クラスターから既存のデータがすべて削除されます。 既存のクラスターのすべてのバックアップ データとスナップショットが保持されます。
[Restore] をクリックします。
Cloud Manager は、復元に必要なストレージ容量を UI で示します。
重要
AES256-GCM で暗号化されたスナップショット復元後のマスター キー ローテーション
Cloud Manager が AES256-GCM を使用して暗号化したスナップショットを復元する場合は、復元の完了後にマスターキーをローテーションします 。
手動復元プロセスでは、次のことを前提としています。
ターゲット ホストには、データがありません。
2 要素認証を有効にしていません。
警告
自動復元を実行できない場合にのみ、スナップショットを手動で復元します。 手動復元を使用する必要があると判断された場合は、 MongoDB サポート にお問い合わせください。 このセクションでは、手動復元手順のステージの概要について説明します。
手動復元プロセスには、MongoDB サポートの支援を受けて実行する次の高レベルのステージがあります。
レガシーの
mongoshell またはmongoshを使用して、各レプリカセットとコンフィギュレーションサーバー レプリカセット（CSRS）に接続します。（任意） 各レプリカセットと CSRS の構成ファイルを確認します。 復元プロセスが完了したら、保存された構成ファイルを使用して復元されたレプリカセットの構成を再構築できます。
完全な手動復元手順については、 MongoDB Server 4.2のドキュメントを参照してください。 MongoDB 4.4以降の配置については、対応するバージョンのマニュアルを参照してください。
Cloud Manager がスナップショットを自動的に復元するようにするには、次の手順に従います。
MongoDB Cloud ManagerGoContinuous BackupMongoDB Cloud Managerで、プロジェクトの ページにGoします。
まだ表示されていない場合は、目的のプロジェクトを含む組織をナビゲーション バーの Organizations メニューで選択します。
まだ表示されていない場合は、ナビゲーション バーのProjectsメニューから目的のプロジェクトを選択します。
サイドバーの Continuous Backup をクリックします。
[継続的なバックアップ ]ページが表示されます。
復元ポイントを選択します。
バックアップを復元するポイントを選択します。
復元タイプ説明アクションSnapshot
復元する既存のスナップショットを選択します。
Point In Time
スナップショットの復元時間目的として日付と時刻を選択できます。 デフォルトでは、 oplogストアは 24 時間のデータを保存します。
たとえば、
12:00を選択した場合、復元の最後の操作は11:59:59またはそれ以前のバージョンになります。重要:
FCV4.0またはそれ以前のバージョンを実行するシャーディングされたシャーディングされたクラスターを復元する場合は、 シャーディングされたシャーディングされたクラスターで PIT 復元を実行するためにクラスター チェックポイントを有効にする必要があります。日付と時刻を含むチェックポイントが利用できない場合、 Cloud Managerはchoose another point in time を要求します。重要:最新のバックアップ再同期の前の時間をカバーするPIT復元は実行できません。 再同期を引き起こす条件については、「バックアップの再同期 」を参照してください。
DateとTimeを選択します。
[Next] をクリックします。
またはそれ以前のバージョンを実行するシャーディングされたシャーディングされたクラスターを復元し、
FCV4.0 Point In Timeを選択した場合:選択した時間に最も近いCheckpointsのリストが表示されます。
ポイントインタイム復元を開始するには、以下の手順を実行します。
リストされているチェックポイントのいずれかを選択するか、
[ Choose another point in timeをクリックしてチェックポイントのリストを削除し、メニューから別の日付と時刻を選択します。
を選択して、ファイルを別のクラスターに復元します。
[Choose Cluster to Restore to] をクリックします。
次のフィールドを入力します。
フィールドアクションProject
スナップショット を復元する プロジェクト を選択します。
Cluster to Restore to
スナップショットを復元するクラスターを選択します。
Cloud Manager は、ターゲットのシャーディングされたクラスターを管理する必要があります。
警告:オートメーションにより、クラスターから既存のデータがすべて削除されます。 既存のクラスターのすべてのバックアップ データとスナップショットが保持されます。
[Restore] をクリックします。
Cloud Manager は、コンソールで復元に必要なストレージ領域の量を示します。
重要
AES256-GCM で暗号化されたスナップショット復元後のマスター キー ローテーション
Cloud Manager が AES256-GCM を使用して暗号化したスナップショットを復元する場合は、復元の完了後にマスターキーをローテーションします 。
手動復元プロセスでは、次のことを前提としています。
ターゲット ホストには、データがありません。
2 要素認証を有効にしていません。
警告
自動復元を実行できない場合にのみ、スナップショットを手動で復元します。 手動復元を使用する必要があると判断された場合は、 MongoDB サポート にお問い合わせください。 このセクションでは、手動復元手順のステージの概要について説明します。
手動復元プロセスには、MongoDB サポートの支援を受けて実行する次の高レベルのステージがあります。
レガシーの
mongoshell またはmongoshを使用して、各レプリカセットとコンフィギュレーションサーバー レプリカセット（CSRS）に接続します。（任意） 各レプリカセットと CSRS の構成ファイルを確認します。 復元プロセスが完了したら、保存された構成ファイルを使用して復元されたレプリカセットの構成を再構築できます。
手動復元の完全な手順については、 MongoDB Server のドキュメント を参照してください。