Docs Menu
Docs Home
/
MongoDB Cloud Manager
/ /

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

項目一覧

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

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

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

Tip

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

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

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

  • groupName

  • ReplicaSetName

  • クラスター ID (該当する場合)

  • スナップショット タイムスタンプ(UTC のタイムスタンプ)

  • タイムスタンプの復元(UTC の BSON タイムスタンプとして)

  • 最後に適用された oplog (UTC の BSON タイムスタンプとして)

  • MongoDB バージョン

  • ストレージ エンジンの種類

  • mongod スナップショットの取得時にデータベースで使用されたスタートアップオプション

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

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

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

  • 新しいホスト名を持つ新しいシステムに復元し、新しい配置が実行中以降にアプリケーション コードを再構成する。または、

  • データの復元中に MongoDB 配置がクライアント リクエストを受信しないことを確認します。

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

1
  1. まだ表示されていない場合は、目的のプロジェクトを含む組織をナビゲーション バーの Organizations メニューで選択します。

  2. まだ表示されていない場合は、ナビゲーション バーのProjectsメニューから目的のプロジェクトを選択します。

  3. サイドバーの Continuous Backup をクリックします。

    [継続的なバックアップ ]ページが表示されます。

2
3
4
  1. バックアップを復元するポイントを選択します。

    復元タイプ
    説明
    アクション

    Snapshot

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

    Point In Time

    選択した時間までのすべての操作を含むカスタム スナップショットを作成します(選択した時間は含みません)。 デフォルトでは、 oplogストアは 24 時間のデータを保存します。

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

    重要: FCV 4.0では、最新のバックアップ再同期の前の時間をカバーするPIT復元は実行できません。 再同期を引き起こす条件については、「バックアップの再同期 」を参照してください。 この注は FCV 4.2以降には適用されません。

    DateTimeを選択します。

    Oplog Timestamp

    入力されたoplogのタイムスタンプまでのすべての操作を含むカスタム スナップショットを作成します。 oplogタイムスタンプには次の 2 つのフィールドが含まれています。

    Timestamp

    UNIXエポック からの経過秒数におけるタイムスタンプ

    Increment

    その秒に適用される操作の順序を 32 ビット序数として表します。

    oplog TimestampIncrement を入力します。

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

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

5
  1. [Choose Cluster to Restore to] をクリックします。

  2. 次のフィールドを入力します。

    フィールド
    アクション

    Project

    Cluster to Restore to

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

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

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

  1. [Restore] をクリックします。

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

6

警告

自動復元を検討する

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

1
  1. まだ表示されていない場合は、目的のプロジェクトを含む組織をナビゲーション バーの Organizations メニューで選択します。

  2. まだ表示されていない場合は、ナビゲーション バーのProjectsメニューから目的のプロジェクトを選択します。

  3. サイドバーの Continuous Backup をクリックします。

    [継続的なバックアップ ]ページが表示されます。

2
3
4
  1. バックアップを復元するポイントを選択します。

    復元タイプ
    説明
    アクション

    Snapshot

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

    Point In Time

    選択した時間までのすべての操作を含むカスタム スナップショットを作成します(選択した時間は含みません)。 デフォルトでは、 oplogストアは 24 時間のデータを保存します。

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

    重要: FCV 4.0では、最新のバックアップ再同期の前の時間をカバーするPIT復元は実行できません。 再同期を引き起こす条件については、「バックアップの再同期 」を参照してください。 この注は FCV 4.2以降には適用されません。

    DateTimeを選択します。

    Oplog Timestamp

    入力されたoplogのタイムスタンプまでのすべての操作を含むカスタム スナップショットを作成します。 oplogタイムスタンプには次の 2 つのフィールドが含まれています。

    Timestamp

    UNIXエポック からの経過秒数におけるタイムスタンプ

    Increment

    その秒に適用される操作の順序を 32 ビット序数として表します。

    oplog TimestampIncrement を入力します。

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

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

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

    Pull Restore Usage Limit

    リンクを使用できる回数を選択します。 No Limitを選択した場合、リンクは有効期限が切れるまで再利用可能です。

    Restore Link Expiration (in hours)

    リンクの有効期限が切れるまでの時間数を選択します。 デフォルト値は1です。 最大値は、選択したスナップショットの有効期限が切れるまでの時間数です。

  2. [Finalize Request] をクリックします。

  3. 2 FAを使用する場合、Cloud Manager は2 FA コードの入力を要求します。 2 FA コードを入力し、 Finalize Requestをクリックします。

7
  1. まだ表示されていない場合は、目的のプロジェクトを含む組織をナビゲーション バーの Organizations メニューで選択します。

  2. まだ表示されていない場合は、ナビゲーション バーのProjectsメニューから目的のプロジェクトを選択します。

  3. サイドバーの Continuous Backup をクリックします。

    [継続的なバックアップ ]ページが表示されます。

8

Cloud Manager はスナップショットへのリンクを作成します。 デフォルトでは、これらのリンクは 1 時間利用でき、使用できるのは 1 回だけです。

スナップショットをダウンロードするには:

  1. [Restore History] をクリックします。

  2. 復元ジョブが完了したら、表示されるレプリカセットごとに [ (get link) ] をクリックします。

  3. クリック:

    • 後で使用するためにリンクをコピーするための、リンクの右側のコピーボタン、または

    • Download スナップショットをすぐにダウンロードする

9

データの手動復元を試みる前に、オートメーションからレプリカセットを削除します。

Unmanage this item in Ops Managers but continue to monitorオプションを選択します。

10

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

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

ストレージ容量

ターゲット ホストのハードウェアには、復元されたデータを保存するための十分な空きストレージ領域が必要です。 このホスト上に既存のクラスター データを保持する場合は、ホストがクラスター データと復元されたデータに十分な空き領域があることを確認してください。

MongoDB バージョン

復元のターゲット ホストと復元のソース ホストは、同じバージョンの MongoDB Server を実行する必要があります。 MongoDB のバージョンを確認するには、ターミナルまたは shell からmongod --versionを実行します。

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

12

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

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

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

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

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

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

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

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

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

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

14

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

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

mongosh --port <ephemeralPort>

mongoshmongodに接続した後、続行します。

15

手動復元を実行するには、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 })
16

次のドキュメントをlocalデータベースのsystem.replsetコレクションに挿入します。 次の変数を変更します。

  • <replaceMeWithTheReplicaSetName> に、レプリカセットの名前を設定します。 この名前は古い名前と同じである必要はありません。

  • <host> このレプリカセット ノードを提供するホストに渡す追加オプション。

  • <ephemeralPortNewReplicaSet> 使用して、新しいレプリカセットのエフェメラル ポートに接続します。 これは、この手順のステップ11で指定した<ephemeralPort>とは異なるポートである必要があります。

1db.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>" }
17

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

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

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

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

restoreInfo.txtファイルのRestore Timestampフィールドに指定されている値にoplogTruncateAfterPointドキュメントを設定します。

そのファイルのRestore Timestampフィールドには 2 つの値が含まれています。 次の例では、最初の値は タイムスタンプ で、2 番目の値は増分です。

1...
2Restore timestamp: (1609947369, 2)
3Last Oplog Applied: Wed Jan 06 15:36:09 GMT 2021 (1609947369, 1)
4MongoDB 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以降のスナップショットには適用されません。

19

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

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

次のコマンドを使用して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>
21

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

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

この手順は任意です。 ポイントインタイム復元が必要な場合は、それを実行します。 この手順が必要な場合は、それを完了してから、ステップ21と22を実行します。 この手順が必要ない場合は、ステップ23に進みます。 この手順では、レプリカセットのターゲット インスタンスで MongoDB バックアップ復元ユーティリティをダウンロードして実行し、 インスタンスを停止します。

  1. MongoDB バックアップ復元ユーティリティをホストにダウンロードします。

    復元パネルを閉じた場合は、 Continuous Backup in DeploymentMoreDownload MongoDB Backup Restore Utilityの順にクリックします。

  2. 抽出したスナップショット ディレクトリをデータディレクトリとして使用し、認証を有効にせずにmongodインスタンスを起動します。 パスによっては、 mongodバイナリへのパスを指定する必要がある場合があります。

    mongod --port <ephemeralPort> \
    --dbpath </path/to/datafiles> \
    --setParameter ttlMonitorEnabled=false

    警告

    MongoDB バックアップ復元ユーティリティは認証をサポートしていないため、認証を使用してこの一時データベースを起動することはできません。

  3. ターゲット ホストで 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

    必須

    mongodoplog を適用する を提供するホストのポートを指定します。

    --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 を に適用するために TLSmongod / 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コマンドをコピーした場合、このフィールドが事前構成されているということを意味します。

  4. インスタンスでmongodを停止します。 パスによっては、 mongoshへのパスを指定する必要がある場合があります。 実行:

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

この手順は、ステップ20を実行した場合にのみ必要です。 ステップ20を実行する必要がなかった場合は、ステップ23に進みます。 次のコマンドを使用してmongodを起動します。 mongodは oplog をRestore timestampまで再生します。 パスによっては、 mongodバイナリへのパスを指定する必要がある場合があります。

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

この手順を完了すると、実際の復元プロセスが完了します。 次の手順では、レプリカセットの構成を復元し、再インポートします。

24

この手順は、ステップ20を実行した場合にのみ必要です。 ステップ20を実行する必要がなかった場合は、ステップ23に進みます。

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

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

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

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

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

26

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

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

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

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

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

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

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
30

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

rs.initiate()
rs.add( { host: "<host2>:<port>" } )
rs.add( { host: "<host3>:<port>" } )
31
  1. まだ表示されていない場合は、目的のプロジェクトを含む組織をナビゲーション バーの Organizations メニューで選択します。

  2. まだ表示されていない場合は、ナビゲーション バーのProjectsメニューから目的のプロジェクトを選択します。

  3. Deployment ページがまだ表示されていない場合は、サイドバーの Deployment をクリックします。

    配置ページが表示されます。

32

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

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

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

1
  1. まだ表示されていない場合は、目的のプロジェクトを含む組織をナビゲーション バーの Organizations メニューで選択します。

  2. まだ表示されていない場合は、ナビゲーション バーのProjectsメニューから目的のプロジェクトを選択します。

  3. サイドバーの Continuous Backup をクリックします。

    [継続的なバックアップ ]ページが表示されます。

2
3
4
  1. バックアップを復元するポイントを選択します。

    復元タイプ
    説明
    アクション

    Snapshot

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

    Point In Time

    選択した時間までのすべての操作を含むカスタム スナップショットを作成します(選択した時間は含みません)。 デフォルトでは、 oplogストアは 24 時間のデータを保存します。

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

    重要: FCV 4.0では、最新のバックアップ再同期の前の時間をカバーするPIT復元は実行できません。 再同期を引き起こす条件については、「バックアップの再同期 」を参照してください。 この注は FCV 4.2以降には適用されません。

    DateTimeを選択します。

    Oplog Timestamp

    入力されたoplogのタイムスタンプまでのすべての操作を含むカスタム スナップショットを作成します。 oplogタイムスタンプには次の 2 つのフィールドが含まれています。

    Timestamp

    UNIXエポック からの経過秒数におけるタイムスタンプ

    Increment

    その秒に適用される操作の順序を 32 ビット序数として表します。

    oplog TimestampIncrement を入力します。

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

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

5
  1. [Choose Cluster to Restore to] をクリックします。

  2. 次のフィールドを入力します。

    フィールド
    アクション

    Project

    Cluster to Restore to

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

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

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

  1. [Restore] をクリックします。

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

6
1
  1. まだ表示されていない場合は、目的のプロジェクトを含む組織をナビゲーション バーの Organizations メニューで選択します。

  2. まだ表示されていない場合は、ナビゲーション バーのProjectsメニューから目的のプロジェクトを選択します。

  3. サイドバーの Continuous Backup をクリックします。

    [継続的なバックアップ ]ページが表示されます。

2
3
4
  1. バックアップを復元するポイントを選択します。

    復元タイプ
    説明
    アクション

    Snapshot

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

    Point In Time

    選択した時間までのすべての操作を含むカスタム スナップショットを作成します(選択した時間は含みません)。 デフォルトでは、 oplogストアは 24 時間のデータを保存します。

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

    重要: FCV 4.0では、最新のバックアップ再同期の前の時間をカバーするPIT復元は実行できません。 再同期を引き起こす条件については、「バックアップの再同期 」を参照してください。 この注は FCV 4.2以降には適用されません。

    DateTimeを選択します。

    Oplog Timestamp

    入力されたoplogのタイムスタンプまでのすべての操作を含むカスタム スナップショットを作成します。 oplogタイムスタンプには次の 2 つのフィールドが含まれています。

    Timestamp

    UNIXエポック からの経過秒数におけるタイムスタンプ

    Increment

    その秒に適用される操作の順序を 32 ビット序数として表します。

    oplog TimestampIncrement を入力します。

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

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

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

    Pull Restore Usage Limit

    リンクを使用できる回数を選択します。 No Limitを選択した場合、リンクは有効期限が切れるまで再利用可能です。

    Restore Link Expiration (in hours)

    リンクの有効期限が切れるまでの時間数を選択します。 デフォルト値は1です。 最大値は、選択したスナップショットの有効期限が切れるまでの時間数です。

  2. [Finalize Request] をクリックします。

  3. 2 FAを使用する場合、Cloud Manager は2 FA コードの入力を要求します。 2 FA コードを入力し、 Finalize Requestをクリックします。

7
  1. まだ表示されていない場合は、目的のプロジェクトを含む組織をナビゲーション バーの Organizations メニューで選択します。

  2. まだ表示されていない場合は、ナビゲーション バーのProjectsメニューから目的のプロジェクトを選択します。

  3. サイドバーの Continuous Backup をクリックします。

    [継続的なバックアップ ]ページが表示されます。

8

Cloud Manager はスナップショットへのリンクを作成します。 デフォルトでは、これらのリンクは 1 時間利用可能で、使用は 1 回だけです。

スナップショットをダウンロードするには:

  1. [Restore History] をクリックします。

  2. 復元ジョブが完了したら、表示される各レプリカセットの [ (get link) ] をクリックします。

  3. クリック:

    • 後で使用するためにリンクをコピーするための、リンクの右側のコピーボタン、または

    • Download スナップショットをすぐにダウンロードする

重要

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

ポイントインタイム復元と oplog タイムスタンプ復元の場合、追加の手順が表示されます。 最後の手順では、 MBRUを使用して実行する必要がある完全なコマンドを示します。 これには、完全な復元を確保するために必要なオプションが すべて 含まれています。

Run Binary with PIT Optionsで提供されているmongodb-backup-restore-utilコマンドを選択してコピーします。

9

tar -xvf <backupSnapshot>.tar.gz
mv <backupSnapshot> <temp-database-path>
10
  1. MongoDB バックアップ復元ユーティリティをホストにダウンロードします。

    注意

    復元パネルを閉じた場合:

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

      1. まだ表示されていない場合は、目的のプロジェクトを含む組織をナビゲーション バーの Organizations メニューで選択します。

      2. まだ表示されていない場合は、ナビゲーション バーのProjectsメニューから目的のプロジェクトを選択します。

      3. サイドバーの Continuous Backup をクリックします。

      [継続的なバックアップ ]ページが表示されます。

    2. MoreDownload MongoDB Backup Restore Utilityをクリックし、 をクリックします。

  2. 抽出したスナップショット ディレクトリをデータディレクトリとして使用し、認証を有効にせずにmongodインスタンスを起動します。

    mongod --port <port number> \
    --dbpath <temp-database-path> \
    --setParameter ttlMonitorEnabled=false

    警告

    MongoDB バックアップ復元ユーティリティは認証をサポートしていないため、認証を使用してこの一時データベースを起動することはできません。

  3. 宛先ホストで 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

    必須

    mongodoplog を適用する を提供するホストのポートを指定します。

    --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 を に適用するために TLSmongod / 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コマンドをコピーした場合、このフィールドが事前構成されているということを意味します。

11

データの手動復元を試みる前に、オートメーションからレプリカセットを削除します。

12

MongoDB マニュアルのチュートリアルに従ってレプリカセットを復元します。

13

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

重要

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

Cloud Manager が AES256-GCM を使用して暗号化したスナップショットを復元する場合は、復元の完了後にマスターキーをローテーションします

戻る

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