スナップショットからレプリカセットを復元
- Cloud Managerへのプログラムによるアクセスのための OAuth 2.0認証はプレビュー機能として利用できます。
- 機能および関連するドキュメントは、プレビュー期間中にいつでも変更される可能性があります。 OAuth2.0 認証を使用するには、 Cloud Manager Public APIへのリクエストで使用する サービス アカウント を作成します。
バックアップからレプリカセットを復元すると、Cloud Manager は選択した復元ポイントの復元ファイルを提供します。 復元プロセスの詳細については、「復元の概要 」を参照してください。
Considerations
BinData
BSONサブタイプへの変更を確認する
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
スナップショットの取得時にデータベースで使用されたスタートアップオプション
バックアップに関する考慮事項
すべての FCVデータベースは、適切なバックアップに関する考慮事項を満たしている必要があります。
前提条件
手動復元を実行するには、Cloud Manager でバックアップ管理者ロールが必要です。
復元中のクライアントリクエスト
復元中に 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 は、復元に必要なストレージ容量の量を示します。
警告
自動復元を検討する
この手順には、多数のステップが含まれます。 これらの手順の一部は、セキュリティに重大な影響を与えます。 Cloud Manager が管理していない配置に復元する必要がない場合は、自動復元を検討してください。
MongoDB Cloud ManagerGoContinuous BackupMongoDB Cloud Managerで、プロジェクトの ページにGoします。
まだ表示されていない場合は、目的のプロジェクトを含む組織をナビゲーション バーの 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] をクリックします。
スナップショットのダウンロードを構成します。
次のダウンロード オプションを設定します。
Pull Restore Usage Limit
リンクを使用できる回数を選択します。
No Limit
を選択した場合、リンクは有効期限が切れるまで再利用可能です。Restore Link Expiration (in hours)
リンクの有効期限が切れるまでの時間数を選択します。 デフォルト値は
1
です。 最大値は、選択したスナップショットの有効期限が切れるまでの時間数です。[Finalize Request] をクリックします。
2 FAを使用する場合、Cloud Manager は2 FA コードの入力を要求します。 2 FA コードを入力し、 Finalize Requestをクリックします。
MongoDB Cloud ManagerGoContinuous BackupMongoDB Cloud Managerで、プロジェクトの ページにGoします。
まだ表示されていない場合は、目的のプロジェクトを含む組織をナビゲーション バーの Organizations メニューで選択します。
まだ表示されていない場合は、ナビゲーション バーのProjectsメニューから目的のプロジェクトを選択します。
サイドバーの Continuous Backup をクリックします。
[継続的なバックアップ ]ページが表示されます。
Retrieve the Snapshots.
Cloud Manager はスナップショットへのリンクを作成します。 デフォルトでは、これらのリンクは 1 時間利用でき、使用できるのは 1 回だけです。
スナップショットをダウンロードするには:
[Restore History] をクリックします。
復元ジョブが完了したら、表示されるレプリカセットごとに [ (get link) ] をクリックします。
クリック:
後で使用するためにリンクをコピーするための、リンクの右側のコピーボタン、または
Download スナップショットをすぐにダウンロードする
ターゲット レプリカセットの管理を解除します。
データの手動復元を試みる前に、オートメーションからレプリカセットを削除します。
Unmanage this item in Ops Managers but continue to monitorオプションを選択します。
ターゲット レプリカセットを停止します。
パスによっては、 mongosh
へのパスを指定する必要がある場合があります。 実行:
mongosh --port <port> \ --eval "db.getSiblingDB('admin').shutdownServer()"
ターゲット レプリカセットでハードウェアとソフトウェアの要件を確認します。
ストレージ容量 | ターゲット ホストのハードウェアには、復元されたデータを保存するための十分な空きストレージ領域が必要です。 このホスト上に既存のクラスター データを保持する場合は、ホストがクラスター データと復元されたデータに十分な空き領域があることを確認してください。 |
MongoDB バージョン | 復元のターゲット ホストと復元のソース ホストは、同じバージョンの MongoDB Server を実行する必要があります。 MongoDB のバージョンを確認するには、ターミナルまたは shell から |
詳細については、「インストール 」を参照してください。
エフェメラル ポートで一時スタンドアロン インスタンスを起動します。
一時的な測定値として、 mongod
プロセスをスタンドアロン モードで開始します。 これにより、後続のステップでsystem.replset
コレクションに新しい構成パラメータを追加できるようになります。
この手順のすべてのステップで、一時的なスタンドアロンのmongod
プロセスに<ephemeralPort>
を使用します。 このポートは、ソースおよびターゲットのホスト ポートとは異なる必要があります。
次のようにmongod
プロセスを実行します。 パスによっては、 mongod
バイナリへのパスを指定する必要がある場合があります。
mongod --dbpath </path/to/datafiles> \ --port <ephemeralPort> \
名前空間でフィルタリングされたスナップショットから復元する場合は、 --restore
オプションを使用します。
mongod --dbpath </path/to/datafiles> \ --port <ephemeralPort> \ --restore
mongod
プロセスが接続を受け入れ始めたら、続行します。
レプリカセット関連のコレクションをlocal
データベースから削除する。
手動復元を実行するには、Cloud Manager でバックアップ管理者ロールが必要です。
次のコマンドを実行して、以前のレプリカセット構成とその他の oplog 以外のレプリケーション関連のコレクションを削除します。
db.getSiblingDB("local").replset.minvalid.drop() db.getSiblingDB("local").replset.oplogTruncateAfterPoint.drop() db.getSiblingDB("local").replset.election.drop() db.getSiblingDB("local").system.replset.remove({})
成功した応答は次のようになります。
> db.getSiblingDB("local").replset.minvalid.drop() true > db.getSiblingDB("local").replset.oplogTruncateAfterPoint.drop() true > db.getSiblingDB("local").replset.election.drop() true > db.getSiblingDB("local").system.replset.remove({}) WriteResult({ "nRemoved" : 1 })
新しいレプリカセット構成の追加。
次のドキュメントをlocal
データベースのsystem.replset
コレクションに挿入します。 次の変数を変更します。
<replaceMeWithTheReplicaSetName>
に、レプリカセットの名前を設定します。 この名前は古い名前と同じである必要はありません。<host>
このレプリカセット ノードを提供するホストに渡す追加オプション。<ephemeralPortNewReplicaSet>
使用して、新しいレプリカセットのエフェメラル ポートに接続します。 これは、この手順のステップ11で指定した<ephemeralPort>
とは異なるポートである必要があります。
1 db.getSiblingDB("local").system.replset.insertOne({ 2 "_id" : "<replaceMeWithTheReplicaSetName>", 3 "version" : NumberInt(1), 4 "protocolVersion" : NumberInt(1), 5 "members" : [ 6 { 7 "_id" : NumberInt(0), 8 "host" : "<host>:<ephemeralPortNewReplicaSet>" 9 } 10 ], 11 "settings" : { 12 13 } 14 })
成功した応答は次のようになります。
{ "acknowledged" : true, "insertedId" : "<yourReplicaSetName>" }
復元ポイントを からRestore Timestamp
restoreInfo.txt
の値に設定します。
restoreInfo.txtファイルのRestore Timestamp
フィールドに指定されている値にoplogTruncateAfterPoint
ドキュメントを設定します。
そのファイルのRestore Timestamp
フィールドには 2 つの値が含まれています。 次の例では、最初の値は タイムスタンプ で、2 番目の値は増分です。
1 ... 2 Restore timestamp: (1609947369, 2) 3 Last Oplog Applied: Wed Jan 06 15:36:09 GMT 2021 (1609947369, 1) 4 MongoDB Version: 4.2.11 5 ...
次のサンプル コードでは、前の例のタイムスタンプ値と増分値を使用します。
truncateAfterPoint = Timestamp(1609947369,2) db.getSiblingDB("local").replset.oplogTruncateAfterPoint.insertOne({ "_id": "oplogTruncateAfterPoint", "oplogTruncateAfterPoint": truncateAfterPoint })
成功した応答は次のようになります。
WriteResult({ "nInserted" : 1 })
注意
MongoDB 4.2の復元 MongoDB 4.4を使用したスナップショット
MongoDB 4.4を実行中のmongod
で MongoDB 4.2のスナップショットを復元しようとすると、oplog に不要なドキュメントが含まれる可能性があります。
この問題を解決するには、次のいずれかを実行します。
タイムスタンプを1ずつ減算します。
MongoDB 4.2を使用して復元します。
Cloud Manager に自動復元を実行させます。
この問題は、MongoDB 4.4以降のスナップショットには適用されません。
一時スタンドアロン インスタンスを停止します。
パスによっては、 mongosh
へのパスを指定する必要がある場合があります。 実行:
mongosh --port <ephemeralPort> \ --eval "db.getSiblingDB('admin').shutdownServer()"
oplog を回復するには、 インスタンスを再起動します。
次のコマンドを使用してmongod
を起動し、これらのパラメータを指定します。
<bind_ip>
この手順のステップ14で指定した、このレプリカセット ノードを提供するホストに接続します。<port>
に、この手順のステップ<ephemeralPort> で指定した11 を設定します。
mongod
は oplog をRestore timestamp
まで再生します。
mongod --dbpath </path/to/datafiles> \ --port <ephemeralPort> \ --bind_ip <host-serving-this-replica-set-member> \ --replSet <replaceMeWithTheReplicaSetName>
エフェメラル ポートの一時インスタンスを停止します。
パスによっては、 mongosh
へのパスを指定する必要がある場合があります。 実行:
mongosh --port <ephemeralPort> \ --eval "db.getSiblingDB('admin').shutdownServer()"
(ポイントインタイム復元のみ) MongoDB バックアップ復元ユーティリティを実行します。
この手順は任意です。 ポイントインタイム復元が必要な場合は、それを実行します。 この手順が必要な場合は、それを完了してから、ステップ21と22を実行します。 この手順が必要ない場合は、ステップ23に進みます。 この手順では、レプリカセットのターゲット インスタンスで MongoDB バックアップ復元ユーティリティをダウンロードして実行し、 インスタンスを停止します。
MongoDB バックアップ復元ユーティリティをホストにダウンロードします。
復元パネルを閉じた場合は、 Continuous Backup in Deployment 、 More 、 Download MongoDB Backup Restore Utilityの順にクリックします。
抽出したスナップショット ディレクトリをデータディレクトリとして使用し、認証を有効にせずに
mongod
インスタンスを起動します。 パスによっては、mongod
バイナリへのパスを指定する必要がある場合があります。mongod --port <ephemeralPort> \ --dbpath </path/to/datafiles> \ --setParameter ttlMonitorEnabled=false 警告
MongoDB バックアップ復元ユーティリティは認証をサポートしていないため、認証を使用してこの一時データベースを起動することはできません。
ターゲット ホストで MongoDB バックアップ復元ユーティリティを実行します。 レプリカセットに対してそれを 1 回実行します。
重要
事前構成された mongodb-backup-restore-tools コマンド
Cloud Manager は、
mongodb-backup-restore-util
の下の復元パネルで、復元に適切なオプションを含むRun Binary with PIT Options を提供します。Cloud Manager に提供される
mongodb-backup-restore-util
コマンドをコピーする必要があります。./mongodb-backup-restore-util --https --host <targetHost> \ --port <targetPort> \ --opStart <opLogStartTimeStamp> \ --opEnd <opLogEndTimeStamp> \ --logFile <logPath> \ --apiKey <apiKey> \ --groupId <groupId> \ --rsId <rsId> \ --whitelist <database1.collection1, database2, etc.> \ --blacklist <database1.collection1, database2, etc.> \ --seedReplSetMember \ --oplogSizeMB <size> \ --seedTargetPort <port> \ --ssl \ --sslCAFile </path/to/ca.pem> \ --sslPEMKeyFile </path/to/pemkey.pem> --sslClientCertificateSubject <distinguishedName> \ --sslRequireValidServerCertificates <true|false> \ --sslServerClientCertificate </path/to/client.pem> \ --sslServerClientCertificatePassword <password> \ --sslRequireValidMMSBackupServerCertificate <true|false> \ --sslTrustedMMSBackupServerCertificate </path/to/mms-certs.pem> \ --httpProxy <proxyURL> mongodb-backup-restore-util
コマンドは、次のオプションを使用します。オプション必要性説明--host
必須
--port
必須
--opStart
必須
復元に含める最初の oplog エントリの BSON タイムスタンプ を指定します。この情報は、ダウンロードされたスナップショットを含む
restoreInfo.txt
ファイルの「Last oplog Applied」エントリに表示されます。この値は
--opEnd
値以下である必要があります。--opEnd
必須
復元に含める最後の oplog エントリの BSON タイムスタンプ を指定します。
この値は、oplog の終了よりも大きくすることはできません。
--logFile
任意
MBRUログが書き込まれるファイル名を含むパスを指定します。
--oplogSourceAddr
必須
Cloud Manager リソース エンドポイントへのURLを指定します。
--apiKey
必須
Cloud Manager エージェントAPI キーを提供します。
--groupId
必須
グループID を指定します。
--rsId
必須
レプリカセットID を指定します。
--whitelist
任意
復元を制限するデータベースやコレクションのリストを指定します。
--blacklist
任意
復元対象から除外するデータベースやコレクションのリストを提供します。
--seedReplSetMember
任意
oplogコレクションを再作成し、正しいタイムスタンプでシードするためにレプリカセット ノードが必要な場合は、 を使用します。
--oplogSizeMB
と--seedTargetPort
が必要です。--oplogSizeMB
条件付き
oplogサイズを MB 単位で指定します。
--seedReplSetMember
が設定されている場合は必須です。--seedTargetPort
条件付き
レプリカセットのプライマリのポートを指定します。 これは エフェメラル ポート とは異なる場合があります 使用されています。
--seedReplSetMember
が設定されている場合は必須です。--ssl
条件付き
--sslCAFile
条件付き
証明機関ファイルへのパスを指定します。
--ssl
が設定されている場合は必須です。--sslPEMKeyFile
条件付き
PEM証明書ファイルへのパスを指定します。
--ssl
が設定されている場合は必須です。--sslPEMKeyFilePwd
条件付き
--sslPEMKeyFile
で指定されたPEM証明書ファイルのパスワードを入力します。--ssl
が設定され、かつPEMキー ファイルが暗号化されている場合は必須です。--sslClientCertificateSubject
ターゲット MongoDB プロセスのクライアント証明書サブジェクトまたは識別名(DN)を指定します。
--sslRequireValidServerCertificates
任意
ターゲット MongoDB プロセスが提示する証明書をツールが検証する必要があるかどうかを示すフラグを設定します。
--sslServerClientCertificate
任意
Cloud Manager ホストへの接続に使用するクライアント証明書ファイルへの絶対パスを指定します。
--sslServerClientCertificatePassword
条件付き
Cloud Manager ホストへの接続に使用するクライアント証明書ファイル パスワードへの絶対パスを指定します。
--sslServerClientCertificate
が設定され、その証明書が暗号化されている場合は必須です。--sslRequireValidMMSBackupServerCertificate
任意
Cloud Manager ホストに接続するときに有効な証明書が必要かどうかを示すフラグを設定します。 デフォルト値は
true
です。--sslTrustedMMSBackupServerCertificate
任意
Cloud Manager ホストのPEM形式で、信頼できる証明機関証明書への絶対パスを指定します。 このフラグが提供されない場合は、システムの認証局が使用されます。
--httpProxy
任意
ツールが使用できる HTTP プロキシ サーバーの URL を指定します。
は、Cloud Manager に提供される
mongodb-backup-restore-util
コマンドをコピーした場合、このフィールドが事前構成されているということを意味します。インスタンスで
mongod
を停止します。 パスによっては、mongosh
へのパスを指定する必要がある場合があります。 実行:mongosh --port <ephemeralPort> \ --eval "db.getSiblingDB('admin').shutdownServer()"
(ポイントインタイム復元のみ) oplog を回復するには、 インスタンスを再起動します。
この手順は、ステップ20を実行した場合にのみ必要です。 ステップ20を実行する必要がなかった場合は、ステップ23に進みます。 次のコマンドを使用してmongod
を起動します。 mongod
は oplog をRestore timestamp
まで再生します。 パスによっては、 mongod
バイナリへのパスを指定する必要がある場合があります。
mongod --dbpath </path/to/datafiles> \ --port <ephemeralPort> \ --replSet <replaceMeWithTheReplicaSetName>
この手順を完了すると、実際の復元プロセスが完了します。 次の手順では、レプリカセットの構成を復元し、再インポートします。
(ポイントインタイム復元のみ) エフェメラル ポートで インスタンスを停止します。
この手順は、ステップ20を実行した場合にのみ必要です。 ステップ20を実行する必要がなかった場合は、ステップ23に進みます。
パスによっては、 mongosh
へのパスを指定する必要がある場合があります。 実行:
mongosh--port <ephemeralPort> \ --eval "db.getSiblingDB('admin').shutdownServer()"
スタンドアロン インスタンスを停止します。
パスによっては、 mongosh
へのパスを指定する必要がある場合があります。 実行:
mongosh --port <port> \ --eval "db.getSiblingDB('admin').shutdownServer()"
レプリカセット内のすべてのノードを再起動します。
この時点で、レプリカセット内のデータファイルは一貫した状態ですが、各ノードが相互を認識できるようにレプリカセットの構成を更新する必要があります。
次のコマンドを実行します:
sudo -u mongod <path/to/target_mongod_binary> -f /path/to/datafiles/automation-mongod.conf
次の例では、バージョン4.4.12のすべてのノードを再起動します。 データ パス/data6/node3
を持つエンタープライズ :
sudo -u mongod /var/lib/mongodb-mms-automation/mongodb-linux-x86_64-4.4.12-ent/bin/mongod -f /data6/node3/automation-mongod.conf
MongoDB Cloud ManagerGoDeploymentMongoDB Cloud Managerで、プロジェクトの ページにGoします。
まだ表示されていない場合は、目的のプロジェクトを含む組織をナビゲーション バーの Organizations メニューで選択します。
まだ表示されていない場合は、ナビゲーション バーのProjectsメニューから目的のプロジェクトを選択します。
Deployment ページがまだ表示されていない場合は、サイドバーの Deployment をクリックします。
配置ページが表示されます。
レプリカセットを再インポートします。
オートメーションでレプリカセットを再度管理するには、レプリカセットを Cloud Manager に再度インポートします。
[ Addをクリックし、 Existing MongoDB Deploymentを選択して、クラスターへのAutomationの追加に進みます。
Cloud Manager がスナップショットを自動的に復元するようにするには、次の手順に従います。
MongoDB Cloud ManagerGoContinuous BackupMongoDB Cloud Managerで、プロジェクトの ページにGoします。
まだ表示されていない場合は、目的のプロジェクトを含む組織をナビゲーション バーの 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] をクリックします。
最新のoplogエントリを見つけるには、 mongosh
で次のクエリを実行します。
db.getSiblingDB('local').oplog.rs.find().sort({$natural:-1}).limit(1).pretty()
成功した結果は次のようになります。
{ "ts": Timestamp(1537559320, 1), "h": NumberLong("-2447431566377702740"), "v": 2, "op": "n", "ns": "", "wall": ISODate("2018-09-21T19:48:40.708Z"), "o": { "msg": "initiating set" } }
ts
値の部分は、Timestamp ボックスとIncrement ボックスに必要な値に対応します。
注意
エポック時間を人間が判読できるタイムスタンプに変換するには、 Eポック 変換 のようなツールを使用してみてください
MongoDB はこのサービスをサポートしていません。 その参照は情報提供のみを目的としています。
を選択して、ファイルを別のクラスターに復元します。
[Choose Cluster to Restore to] をクリックします。
次のフィールドを入力します。
フィールドアクションProject
スナップショット を復元する プロジェクト を選択します。
Cluster to Restore to
スナップショットを復元するクラスターを選択します。
Cloud Manager は、ターゲット レプリカセットを管理する必要があります。
警告:オートメーションにより、クラスターから既存のデータがすべて削除されます。 既存のクラスターのすべてのバックアップ データとスナップショットが保持されます。
[Restore] をクリックします。
Cloud Manager は、復元に必要なストレージ容量の量を示します。
MongoDB Cloud ManagerGoContinuous BackupMongoDB Cloud Managerで、プロジェクトの ページにGoします。
まだ表示されていない場合は、目的のプロジェクトを含む組織をナビゲーション バーの 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] をクリックします。
最新のoplogエントリを見つけるには、 mongosh
で次のクエリを実行します。
db.getSiblingDB('local').oplog.rs.find().sort({$natural:-1}).limit(1).pretty()
成功した結果は次のようになります。
{ "ts": Timestamp(1537559320, 1), "h": NumberLong("-2447431566377702740"), "v": 2, "op": "n", "ns": "", "wall": ISODate("2018-09-21T19:48:40.708Z"), "o": { "msg": "initiating set" } }
ts
値の部分は、Timestamp ボックスとIncrement ボックスに必要な値に対応します。
注意
エポック時間を人間が判読できるタイムスタンプに変換するには、 Eポック 変換 のようなツールを使用してみてください
MongoDB はこのサービスをサポートしていません。 その参照は情報提供のみを目的としています。
スナップショットのダウンロードを構成します。
次のダウンロード オプションを設定します。
Pull Restore Usage Limit
リンクを使用できる回数を選択します。
No Limit
を選択した場合、リンクは有効期限が切れるまで再利用可能です。Restore Link Expiration (in hours)
リンクの有効期限が切れるまでの時間数を選択します。 デフォルト値は
1
です。 最大値は、選択したスナップショットの有効期限が切れるまでの時間数です。[Finalize Request] をクリックします。
2 FAを使用する場合、Cloud Manager は2 FA コードの入力を要求します。 2 FA コードを入力し、 Finalize Requestをクリックします。
MongoDB Cloud ManagerGoContinuous BackupMongoDB Cloud Managerで、プロジェクトの ページにGoします。
まだ表示されていない場合は、目的のプロジェクトを含む組織をナビゲーション バーの Organizations メニューで選択します。
まだ表示されていない場合は、ナビゲーション バーのProjectsメニューから目的のプロジェクトを選択します。
サイドバーの Continuous Backup をクリックします。
[継続的なバックアップ ]ページが表示されます。
Retrieve the snapshots.
Cloud Manager はスナップショットへのリンクを作成します。 デフォルトでは、これらのリンクは 1 時間利用可能で、使用は 1 回だけです。
スナップショットをダウンロードするには:
[Restore History] をクリックします。
復元ジョブが完了したら、表示される各レプリカセットの [ (get link) ] をクリックします。
クリック:
後で使用するためにリンクをコピーするための、リンクの右側のコピーボタン、または
Download スナップショットをすぐにダウンロードする
重要
ポイントインタイム復元のための追加ステップ
ポイントインタイム復元と oplog タイムスタンプ復元の場合、追加の手順が表示されます。 最後の手順では、 MBRUを使用して実行する必要がある完全なコマンドを示します。 これには、完全な復元を確保するために必要なオプションが すべて 含まれています。
Run Binary with PIT Optionsで提供されているmongodb-backup-restore-util
コマンドを選択してコピーします。
MongoDB バックアップ復元ユーティリティ(ポイントインタイム復元のみ)を実行します。
MongoDB バックアップ復元ユーティリティをホストにダウンロードします。
注意
復元パネルを閉じた場合:
MongoDB Cloud Managerで、プロジェクトの Continuous Backup ページにGoします。
まだ表示されていない場合は、目的のプロジェクトを含む組織をナビゲーション バーの Organizations メニューで選択します。
まだ表示されていない場合は、ナビゲーション バーのProjectsメニューから目的のプロジェクトを選択します。
サイドバーの Continuous Backup をクリックします。
[継続的なバックアップ ]ページが表示されます。
MoreDownload MongoDB Backup Restore Utilityをクリックし、 をクリックします。
抽出したスナップショット ディレクトリをデータディレクトリとして使用し、認証を有効にせずに
mongod
インスタンスを起動します。例
mongod --port <port number> \ --dbpath <temp-database-path> \ --setParameter ttlMonitorEnabled=false 警告
MongoDB バックアップ復元ユーティリティは認証をサポートしていないため、認証を使用してこの一時データベースを起動することはできません。
宛先ホストで MongoDB バックアップ復元ユーティリティを実行します。 レプリカセットに対してそれを 1 回実行します。
重要
事前構成された mongodb-backup-restore-tools コマンド
Cloud Manager は、
mongodb-backup-restore-util
の下の復元パネルで、復元に適切なオプションを含むRun Binary with PIT Options を提供します。Cloud Manager に提供される
mongodb-backup-restore-util
コマンドをコピーする必要があります。./mongodb-backup-restore-util --https --host <targetHost> \ --port <targetPort> \ --opStart <opLogStartTimeStamp> \ --opEnd <opLogEndTimeStamp> \ --logFile <logPath> \ --apiKey <apiKey> \ --groupId <groupId> \ --rsId <rsId> \ --whitelist <database1.collection1, database2, etc.> \ --blacklist <database1.collection1, database2, etc.> \ --seedReplSetMember \ --oplogSizeMB <size> \ --seedTargetPort <port> \ --ssl \ --sslCAFile </path/to/ca.pem> \ --sslPEMKeyFile </path/to/pemkey.pem> --sslClientCertificateSubject <distinguishedName> \ --sslRequireValidServerCertificates <true|false> \ --sslServerClientCertificate </path/to/client.pem> \ --sslServerClientCertificatePassword <password> \ --sslRequireValidMMSBackupServerCertificate <true|false> \ --sslTrustedMMSBackupServerCertificate </path/to/mms-certs.pem> \ --httpProxy <proxyURL> mongodb-backup-restore-util
コマンドは、次のオプションを使用します。オプション必要性説明--host
必須
--port
必須
--opStart
必須
復元に含める最初の oplog エントリの BSON タイムスタンプ を指定します。この情報は、ダウンロードされたスナップショットを含む
restoreInfo.txt
ファイルの「Last oplog Applied」エントリに表示されます。この値は
--opEnd
値以下である必要があります。--opEnd
必須
復元に含める最後の oplog エントリの BSON タイムスタンプ を指定します。
この値は、oplog の終了よりも大きくすることはできません。
--logFile
任意
MBRUログが書き込まれるファイル名を含むパスを指定します。
--oplogSourceAddr
必須
Cloud Manager リソース エンドポイントへのURLを指定します。
--apiKey
必須
Cloud Manager エージェントAPI キーを提供します。
--groupId
必須
グループID を指定します。
--rsId
必須
レプリカセットID を指定します。
--whitelist
任意
復元を制限するデータベースやコレクションのリストを指定します。
--blacklist
任意
復元対象から除外するデータベースやコレクションのリストを提供します。
--seedReplSetMember
任意
oplogコレクションを再作成し、正しいタイムスタンプでシードするためにレプリカセット ノードが必要な場合は、 を使用します。
--oplogSizeMB
と--seedTargetPort
が必要です。--oplogSizeMB
条件付き
oplogサイズを MB 単位で指定します。
--seedReplSetMember
が設定されている場合は必須です。--seedTargetPort
条件付き
レプリカセットのプライマリのポートを指定します。 これは エフェメラル ポート とは異なる場合があります 使用されています。
--seedReplSetMember
が設定されている場合は必須です。--ssl
条件付き
--sslCAFile
条件付き
証明機関ファイルへのパスを指定します。
--ssl
が設定されている場合は必須です。--sslPEMKeyFile
条件付き
PEM証明書ファイルへのパスを指定します。
--ssl
が設定されている場合は必須です。--sslPEMKeyFilePwd
条件付き
--sslPEMKeyFile
で指定されたPEM証明書ファイルのパスワードを入力します。--ssl
が設定され、かつPEMキー ファイルが暗号化されている場合は必須です。--sslClientCertificateSubject
ターゲット MongoDB プロセスのクライアント証明書サブジェクトまたは識別名(DN)を指定します。
--sslRequireValidServerCertificates
任意
ターゲット MongoDB プロセスが提示する証明書をツールが検証する必要があるかどうかを示すフラグを設定します。
--sslServerClientCertificate
任意
Cloud Manager ホストへの接続に使用するクライアント証明書ファイルへの絶対パスを指定します。
--sslServerClientCertificatePassword
条件付き
Cloud Manager ホストへの接続に使用するクライアント証明書ファイル パスワードへの絶対パスを指定します。
--sslServerClientCertificate
が設定され、その証明書が暗号化されている場合は必須です。--sslRequireValidMMSBackupServerCertificate
任意
Cloud Manager ホストに接続するときに有効な証明書が必要かどうかを示すフラグを設定します。 デフォルト値は
true
です。--sslTrustedMMSBackupServerCertificate
任意
Cloud Manager ホストのPEM形式で、信頼できる証明機関証明書への絶対パスを指定します。 このフラグが提供されない場合は、システムの認証局が使用されます。
--httpProxy
任意
ツールが使用できる HTTP プロキシ サーバーの URL を指定します。
は、Cloud Manager に提供される
mongodb-backup-restore-util
コマンドをコピーした場合、このフィールドが事前構成されているということを意味します。
レプリカセットの管理を解除します。
データの手動復元を試みる前に、オートメーションからレプリカセットを削除します。
レプリカセットの手動復元。
MongoDB マニュアルのチュートリアルに従ってレプリカセットを復元します。
レプリカセットを再インポートします。
オートメーションでレプリカセットを再度管理するには、レプリカセットを Cloud Manager に再度インポートします。
重要
AES256-GCM で暗号化されたスナップショット復元後のマスター キー ローテーション
Cloud Manager が AES256-GCM を使用して暗号化したスナップショットを復元する場合は、復元の完了後にマスターキーをローテーションします 。