スナップショットからレプリカセットを復元

項目一覧

Considerations

前提条件
スナップショットの復元

Cloud Manager は、 2024年8月30日でMongoDB 3.6と4.0のオートメーション、バックアップおよびモニタリングのサポートを終了します。 MongoDB の配置をアップグレードするか、Atlas に移行してください。

バックアップからレプリカセットを復元すると、Cloud Manager は選択した復元ポイントの復元ファイルを提供します。復元プロセスの詳細については、「復元の概要」を参照してください。

Considerations

BSON サブタイプへの変更を確認する`BinData`

BSON 仕様 BSON バイナリデータ型（BinData ）のデフォルトのサブタイプを2 から0 に変更しました。スナップショットに保存される一部のバイナリデータは、 BinDataサブタイプ2である場合があります。バックアップは、 BinDataサブタイプ2のスナップショットデータを自動的に検出し、 BinDataサブタイプ0に変換します。アプリケーションコードでBinDataサブタイプ2が予測されている場合は、アプリケーションコードを更新してBinDataサブタイプ0で動作するようにする必要があります。

Tip

以下も参照してください。

BSON 仕様に関する注意事項この変更の具体的な内容を説明する。

次で指定された設定を使用して復元します: `restoreInfo.txt`

バックアップ復元ファイルには、 restoreInfo.txtという名前のメタデータファイルが含まれています。このファイルは、スナップショットの取得時にデータベースが使用したオプションをキャプチャします。データベースは、復元した後、リストされているオプションで実行する必要があります。このファイルには、次のものが含まれています。

groupName
ReplicaSetName
クラスター ID （該当する場合）
スナップショットタイムスタンプ（UTC のタイムスタンプ）
タイムスタンプの復元（UTC の BSON タイムスタンプとして）
最後に適用された oplog （UTC の BSON タイムスタンプとして）
MongoDB バージョン
ストレージエンジンの種類
mongod スナップショットの取得時にデータベースで使用されたスタートアップオプション

バックアップに関する考慮事項

すべての FCVデータベースは、適切なバックアップに関する考慮事項を満たしている必要があります。

前提条件

手動復元を実行するには、Cloud Manager でバックアップ管理者ロールが必要です。

復元中のクライアントリクエスト

復元中に MongoDB 配置がクライアントリクエストを受信しないことを確認する必要があります。次のいずれかを行う必要があります。

新しいホスト名を持つ新しいシステムに復元し、新しい配置が実行中以降にアプリケーションコードを再構成する。または、
データの復元中に MongoDB 配置がクライアントリクエストを受信しないことを確認します。

スナップショットの復元

Cloud Manager がスナップショットを自動的に復元するようにするには、次の手順に従います。

MongoDB Cloud Managerで、プロジェクトのGo Continuous Backup{0 ページにします。

まだ表示されていない場合は、目的のプロジェクトを含む組織をナビゲーションバーの Organizations メニューで選択します。
まだ表示されていない場合は、ナビゲーションバーのProjectsメニューから目的のプロジェクトを選択します。
サイドバーの Continuous Backup をクリックします。
[継続的なバックアップ ]ページが表示されます。

Overview タブをクリックします。

配置をクリックし、Restore or Download をクリックします。

復元ポイントを選択します。

バックアップを復元するポイントを選択します。

復元タイプ

説明

アクション

Snapshot

保存されたスナップショットを 1 つ選択できます。

復元する既存のスナップショットを選択します。

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 は、ターゲットレプリカセットを管理する必要があります。警告:オートメーションにより、クラスターから既存のデータがすべて削除されます。既存のクラスターのすべてのバックアップデータとスナップショットが保持されます。

フィールド

アクション

Project

スナップショットを復元するプロジェクトを選択します。

Cluster to Restore to

スナップショットを復元するクラスターを選択します。

Cloud Manager は、ターゲットレプリカセットを管理する必要があります。

警告:オートメーションにより、クラスターから既存のデータがすべて削除されます。既存のクラスターのすべてのバックアップデータとスナップショットが保持されます。

[Restore] をクリックします。
Cloud Manager は、復元に必要なストレージ容量の量を示します。

Restore[ をクリックします。

警告

自動復元を検討する

この手順には、多数のステップが含まれます。これらの手順の一部は、セキュリティに重大な影響を与えます。 Cloud Manager が管理していない配置に復元する必要がない場合は、自動復元を検討してください。

MongoDB Cloud ManagerGoContinuous Backupで、プロジェクトのページにします。

まだ表示されていない場合は、目的のプロジェクトを含む組織をナビゲーションバーの Organizations メニューで選択します。
まだ表示されていない場合は、ナビゲーションバーのProjectsメニューから目的のプロジェクトを選択します。
サイドバーの Continuous Backup をクリックします。
[継続的なバックアップ ]ページが表示されます。

Overview タブをクリックします。

配置をクリックし、Restore or Download をクリックします。

復元ポイントを選択します。

バックアップを復元するポイントを選択します。

復元タイプ

説明

アクション

Snapshot

保存されたスナップショットを 1 つ選択できます。

復元する既存のスナップショットを選択します。

Point In Time

たとえば、 12:00を選択した場合、復元の最後の操作は11:59:59またはそれ以前のバージョンになります。

重要

DateとTimeを選択します。

Oplog Timestamp

Timestamp	UNIXエポックからの経過秒数におけるタイムスタンプ
Increment	その秒に適用される操作の順序を 32 ビット序数として表します。

oplog Timestamp と Increment を入力します。

レプリカセットでlocal.oplog.rsに対してクエリを実行し、目的のタイムスタンプを見つけます。

[Next] をクリックします。

Downloadファイルを手動で復元するには、をクリックします。

スナップショットのダウンロードを構成します。

次のダウンロードオプションを設定します。

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 Backupで、プロジェクトのページにします。

まだ表示されていない場合は、目的のプロジェクトを含む組織をナビゲーションバーの 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 --version`を実行します。

詳細については、「インストール」を参照してください。

スナップショットデータファイルをターゲットホストに移動します。

スナップショットのデータファイルをターゲットホストに移動する前に、ターゲットホストに既存のファイルが含まれているかどうかを確認し、 automation-mongod.confファイルを除くすべてのファイルを削除します。

スナップショットファイルを解凍し、ターゲットホストに移動するには、次のようにします。

tar -xvf <backupSnapshot>.tar.gz
mv <backupSnapshot> </path/to/datafiles>

エフェメラルポートで一時スタンドアロンインスタンスを起動します。

一時的な測定値として、 mongodプロセスをスタンドアロンモードで開始します。これにより、後続のステップでsystem.replsetコレクションに新しい構成パラメータを追加できるようになります。

この手順のすべてのステップで、一時的なスタンドアロンのmongodプロセスに<ephemeralPort>を使用します。このポートは、ソースおよびターゲットのホストポートとは異なる必要があります。

次のようにmongodプロセスを実行します。パスによっては、 mongodバイナリへのパスを指定する必要がある場合があります。

mongod  --dbpath </path/to/datafiles> \
        --port <ephemeralPort> \

名前空間でフィルタリングされたスナップショットから復元する場合は、 --restoreオプションを使用します。

mongod --dbpath </path/to/datafiles> \
       --port <ephemeralPort> \
       --restore

mongodプロセスが接続を受け入れ始めたら、続行します。

を使用して一時スタンドアロン`mongosh` インスタンスに接続します。

このmongodプロセスを実行しているホストから、 mongoshを開始します。パスによっては、 mongoshへのパスを指定する必要がある場合があります。

前のステップで指定された同じ<ephemeralPort> でローカルホストをリッスンしているmongodに接続するには、次のコマンドを実行します。

mongosh  --port <ephemeralPort>

mongoshが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>" }

最小有効タイムスタンプを挿入します。

次のコマンドを発行します:

db.getSiblingDB("local").replset.minvalid.insertOne({
  "_id" : ObjectId(),
  "t" : NumberLong(-1),
  "ts" : Timestamp(0,1)
})

成功した応答は次のようになります。

{ "acknowledged" : true, "insertedId" : ObjectId("<yourObjectId>") }

復元ポイントを`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`	必須	oplog を適用する mongod を提供するホストのホスト名、 FQDN 、 IPv4 アドレス、または IPv6 アドレスを指定します。Cloud Manager で提供される`mongodb-backup-restore-util`コマンドをコピーした場合、このフィールドは事前構成されています。
`--port`	必須	`mongod`oplog を適用するを提供するホストのポートを指定します。
`--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`	条件付き	oplog をに適用するために TLS`mongod` / SSL が必要な場合は、を使用します。 `--sslCAFile`と`--sslPEMKeyFile`が必要です。
`--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()"

レプリカセットをスタンドアロンインスタンスとして再起動します。

次のコマンドを使用して、 mongodプロセスをスタンドアロンインスタンスとして開始します。 <port>には、レプリカセット内のこのノードが実行される実際のポートを使用します。パスによっては、 mongodバイナリへのパスを指定する必要がある場合があります。

mongod  --dbpath </path/to/datafiles> \
        --port <port>

mongodプロセスが接続を受け入れ始めたら、続行します。

一時レプリカセット構成を削除します。

次のコマンドを実行します:

mongosh --port <port> \
      --eval db.getSiblingDB("local").system.replset.remove({})

スタンドアロンインスタンスを停止します。

パスによっては、 mongoshへのパスを指定する必要がある場合があります。実行:

mongosh --port <port> \
      --eval "db.getSiblingDB('admin').shutdownServer()"

レプリカセット内の各ノードに対してステップ10から25を繰り返します。

レプリカセット内のすべてのノードを再起動します。

この時点で、レプリカセット内のデータファイルは一貫した状態ですが、各ノードが相互を認識できるようにレプリカセットの構成を更新する必要があります。

次のコマンドを実行します:

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

レプリカセットの構成を設定します。

ノードの 1 つにログインし、次のコマンドを実行します。

rs.initiate()
rs.add( { host: "<host2>:<port>" } )
rs.add( { host: "<host3>:<port>" } )

MongoDB Cloud ManagerGoDeploymentで、プロジェクトのページにします。

まだ表示されていない場合は、目的のプロジェクトを含む組織をナビゲーションバーの Organizations メニューで選択します。
まだ表示されていない場合は、ナビゲーションバーのProjectsメニューから目的のプロジェクトを選択します。
Deployment ページがまだ表示されていない場合は、サイドバーの Deployment をクリックします。
配置ページが表示されます。

レプリカセットを再インポートします。

オートメーションでレプリカセットを再度管理するには、レプリカセットを Cloud Manager に再度インポートします。

[ Addをクリックし、 Existing MongoDB Deploymentを選択して、クラスターへのAutomationの追加に進みます。

Cloud Manager がスナップショットを自動的に復元するようにするには、次の手順に従います。

MongoDB Cloud ManagerGoContinuous Backupで、プロジェクトのページにします。

まだ表示されていない場合は、目的のプロジェクトを含む組織をナビゲーションバーの Organizations メニューで選択します。
まだ表示されていない場合は、ナビゲーションバーのProjectsメニューから目的のプロジェクトを選択します。
サイドバーの Continuous Backup をクリックします。
[継続的なバックアップ ]ページが表示されます。

Overview タブをクリックします。

配置をクリックし、Restore or Download をクリックします。

復元ポイントを選択します。

バックアップを復元するポイントを選択します。

復元タイプ

説明

アクション

Snapshot

保存されたスナップショットを 1 つ選択できます。

復元する既存のスナップショットを選択します。

Point In Time

たとえば、 12:00を選択した場合、復元の最後の操作は11:59:59またはそれ以前のバージョンになります。

重要

DateとTimeを選択します。

Oplog Timestamp

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 は、ターゲットレプリカセットを管理する必要があります。警告:オートメーションにより、クラスターから既存のデータがすべて削除されます。既存のクラスターのすべてのバックアップデータとスナップショットが保持されます。

フィールド

アクション

Project

スナップショットを復元するプロジェクトを選択します。

Cluster to Restore to

スナップショットを復元するクラスターを選択します。

Cloud Manager は、ターゲットレプリカセットを管理する必要があります。

[Restore] をクリックします。
Cloud Manager は、復元に必要なストレージ容量の量を示します。

Restore[ をクリックします。

MongoDB Cloud ManagerGoContinuous Backupで、プロジェクトのページにします。

まだ表示されていない場合は、目的のプロジェクトを含む組織をナビゲーションバーの Organizations メニューで選択します。
まだ表示されていない場合は、ナビゲーションバーのProjectsメニューから目的のプロジェクトを選択します。
サイドバーの Continuous Backup をクリックします。
[継続的なバックアップ ]ページが表示されます。

Overview タブをクリックします。

配置をクリックし、Restore or Download をクリックします。

復元ポイントを選択します。

バックアップを復元するポイントを選択します。

復元タイプ

説明

アクション

Snapshot

保存されたスナップショットを 1 つ選択できます。

復元する既存のスナップショットを選択します。

Point In Time

たとえば、 12:00を選択した場合、復元の最後の操作は11:59:59またはそれ以前のバージョンになります。

重要

DateとTimeを選択します。

Oplog Timestamp

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 はこのサービスをサポートしていません。その参照は情報提供のみを目的としています。

Downloadファイルを手動で復元するには、をクリックします。

スナップショットのダウンロードを構成します。

次のダウンロードオプションを設定します。

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 Backupで、プロジェクトのページにします。

まだ表示されていない場合は、目的のプロジェクトを含む組織をナビゲーションバーの 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コマンドを選択してコピーします。

スナップショットデータファイルを宛先ホストに復元します。

例

tar -xvf <backupSnapshot>.tar.gz
mv <backupSnapshot> <temp-database-path>

MongoDB バックアップ復元ユーティリティ（ポイントインタイム復元のみ）を実行します。

MongoDB バックアップ復元ユーティリティをホストにダウンロードします。
注意
復元パネルを閉じた場合:
1. MongoDB Cloud Managerで、プロジェクトの Continuous Backup ページにGoします。
  1. まだ表示されていない場合は、目的のプロジェクトを含む組織をナビゲーションバーの Organizations メニューで選択します。
  2. まだ表示されていない場合は、ナビゲーションバーのProjectsメニューから目的のプロジェクトを選択します。
  3. サイドバーの Continuous Backup をクリックします。
  [継続的なバックアップ ]ページが表示されます。
2. 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`	必須	oplog を適用する mongod を提供するホストのホスト名、 FQDN 、 IPv4 アドレス、または IPv6 アドレスを指定します。Cloud Manager で提供される`mongodb-backup-restore-util`コマンドをコピーした場合、このフィールドは事前構成されています。
`--port`	必須	`mongod`oplog を適用するを提供するホストのポートを指定します。
`--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`	条件付き	oplog をに適用するために TLS`mongod` / SSL が必要な場合は、を使用します。 `--sslCAFile`と`--sslPEMKeyFile`が必要です。
`--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 を使用して暗号化したスナップショットを復元する場合は、復元の完了後にマスターキーをローテーションします。

戻る

シャーディングされたクラスターの復元

バックアップスナップショットのクエリ

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	})

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	...

Considerations

Tip

以下も参照してください。

次で指定された設定を使用して復元します: restoreInfo.txt

バックアップに関する考慮事項

前提条件

復元中のクライアントリクエスト

スナップショットの復元

MongoDB Cloud Managerで、プロジェクトのGo .css-h15tq0{font-style:normal;font-weight:700;}Continuous Backup{0 ページに します。

Overview タブをクリックします。

配置をクリックし、Restore or Download をクリックします。

復元ポイントを選択します。

重要

を選択して、ファイルを別のクラスターに復元します。

Restore[ をクリックします。

警告

自動復元を検討する

MongoDB Cloud ManagerGoContinuous Backupで、プロジェクトの ページに します。

Overview タブをクリックします。

配置をクリックし、Restore or Download をクリックします。

復元ポイントを選択します。

重要

Downloadファイルを手動で復元するには、 をクリックします。

スナップショットのダウンロードを構成します。

MongoDB Cloud ManagerGoContinuous Backupで、プロジェクトの ページに します。

Retrieve the Snapshots.

ターゲット レプリカセットの管理を解除します。

ターゲット レプリカセットを停止します。

ターゲット レプリカセットでハードウェアとソフトウェアの要件を確認します。

スナップショット データファイルをターゲット ホストに移動します。

エフェメラル ポートで一時スタンドアロン インスタンスを起動します。

を使用して一時スタンドアロンmongosh インスタンスに接続します。

レプリカセット関連のコレクションをlocal データベースから削除する。

新しいレプリカセット構成の追加。

最小有効タイムスタンプを挿入します。

復元ポイントをRestore Timestamp restoreInfo.txtの値に設定します。

注意

MongoDB 4.2の復元 MongoDB 4.4を使用したスナップショット

一時スタンドアロン インスタンスを停止します。

oplog を回復するには、 インスタンスを再起動します。

エフェメラル ポートの一時インスタンスを停止します。

（ポイントインタイム復元のみ） MongoDB バックアップ復元ユーティリティを実行します。

警告

重要

事前構成された mongodb-backup-restore-tools コマンド

（ポイントインタイム復元のみ） oplog を回復するには、 インスタンスを再起動します。

（ポイントインタイム復元のみ） エフェメラル ポートで インスタンスを停止します。

レプリカセットをスタンドアロン インスタンスとして再起動します。

一時レプリカセット構成を削除します。

スタンドアロン インスタンスを停止します。

レプリカセット内の各ノードに対してステップ10から25を繰り返します。

レプリカセット内のすべてのノードを再起動します。

レプリカセットの構成を設定します。

MongoDB Cloud ManagerGoDeploymentで、プロジェクトの ページに します。

レプリカセットを再インポートします。

MongoDB Cloud ManagerGoContinuous Backupで、プロジェクトの ページに します。

Overview タブをクリックします。

配置をクリックし、Restore or Download をクリックします。

復元ポイントを選択します。

重要

注意

を選択して、ファイルを別のクラスターに復元します。

Restore[ をクリックします。

MongoDB Cloud ManagerGoContinuous Backupで、プロジェクトの ページに します。

Overview タブをクリックします。

配置をクリックし、Restore or Download をクリックします。

復元ポイントを選択します。

重要

注意

Downloadファイルを手動で復元するには、 をクリックします。

スナップショットのダウンロードを構成します。

MongoDB Cloud ManagerGoContinuous Backupで、プロジェクトの ページに します。

Retrieve the snapshots.

重要

ポイントインタイム復元のための追加ステップ

スナップショット データファイルを宛先ホストに復元します。

例

MongoDB バックアップ復元ユーティリティ（ポイントインタイム復元のみ）を実行します。

注意

例

次で指定された設定を使用して復元します: `restoreInfo.txt`

MongoDB Cloud Managerで、プロジェクトのGo Continuous Backup{0 ページにします。

MongoDB Cloud ManagerGoContinuous Backupで、プロジェクトのページにします。

Downloadファイルを手動で復元するには、をクリックします。

MongoDB Cloud ManagerGoContinuous Backupで、プロジェクトのページにします。

ターゲットレプリカセットの管理を解除します。

ターゲットレプリカセットを停止します。

ターゲットレプリカセットでハードウェアとソフトウェアの要件を確認します。

スナップショットデータファイルをターゲットホストに移動します。

エフェメラルポートで一時スタンドアロンインスタンスを起動します。

を使用して一時スタンドアロン`mongosh` インスタンスに接続します。

レプリカセット関連のコレクションを`local` データベースから削除する。

復元ポイントを`Restore Timestamp` `restoreInfo.txt`の値に設定します。

一時スタンドアロンインスタンスを停止します。

oplog を回復するには、インスタンスを再起動します。

エフェメラルポートの一時インスタンスを停止します。

（ポイントインタイム復元のみ） oplog を回復するには、インスタンスを再起動します。

（ポイントインタイム復元のみ）エフェメラルポートでインスタンスを停止します。

レプリカセットをスタンドアロンインスタンスとして再起動します。

スタンドアロンインスタンスを停止します。

MongoDB Cloud ManagerGoDeploymentで、プロジェクトのページにします。

MongoDB Cloud ManagerGoContinuous Backupで、プロジェクトのページにします。

MongoDB Cloud ManagerGoContinuous Backupで、プロジェクトのページにします。

Downloadファイルを手動で復元するには、をクリックします。

MongoDB Cloud ManagerGoContinuous Backupで、プロジェクトのページにします。

スナップショットデータファイルを宛先ホストに復元します。

AES256-GCM で暗号化されたスナップショット復元後のマスターキーローテーション