Docs Menu
Docs Home
/
MongoDB Ops Manager
/ /

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

項目一覧

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

バックアップからレプリカセットを復元すると、 MongoDB Ops 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 の起動オプション

  • 暗号化(スナップショットで暗号化が有効になっている場合にのみ表示されます)

  • マスターキー UUID (スナップショットで暗号化が有効になっている場合にのみ表示されます)

    暗号化されたバックアップから復元する場合は、このマスター キーに対して証明書がプロビジョニングされている必要があります。

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

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

暗号化されたバックアップから復元するには、バックアップの暗号化に使用されるのと同じマスター キーと、バックアップデーモンホスト上のものと同じ証明書、またはKMIPホストからそのキーでプロビジョニングされた新しい証明書が必要です。

スナップショットが暗号化されている場合、復元パネルには KMIP マスター キー ID と KMIP サーバー情報が表示されます。 また、スナップショット自体とrestoreInfo.txtファイルを表示する際にも、 情報を見つけることができます。

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

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

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

重要

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

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

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

1
2
3
  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] をクリックします。

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

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

    フィールド
    アクション
    Project
    Cluster to Restore to

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

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

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

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

    MongoDB Ops Managerは、復元に必要なストレージ領域の量を示します。

5

警告

自動復元を検討する

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

1
2
3
  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] をクリックします。

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

    Pull Restore Usage Limit
    リンクを使用できる回数を選択します。 No Limitを選択した場合、リンクは有効期限が切れるまで再利用可能です。
    Restore Link Expiration (in hours)
    リンクの有効期限が切れるまでの時間数を選択します。 デフォルト値は1です。 最大値は、選択したスナップショットの有効期限が切れるまでの時間数です。
  2. [Finalize Request] をクリックします。

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

6

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

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

  1. 復元パネルを閉じた場合は、 Continuous Backupをクリックし、次にRestore Historyをクリックします。

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

  3. クリック:

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

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

1

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

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

2

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

mongosh --port <port> \
--eval "db.getSiblingDB('admin').shutdownServer()"
3
ストレージ容量
ターゲット ホストのハードウェアには、復元されたデータを保存するための十分な空きストレージ領域が必要です。 このホスト上に既存のクラスター データを保持する場合は、ホストがクラスター データと復元されたデータに十分な空き領域があることを確認してください。
MongoDB バージョン
復元のターゲット ホストと復元のソース ホストは、同じバージョンの MongoDB Server を実行する必要があります。 MongoDB のバージョンを確認するには、ターミナルまたは shell からmongod --versionを実行します。

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

4

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

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

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

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

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

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

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

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

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

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

2

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

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

mongosh --port <ephemeralPort>

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

3

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

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

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

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

  • <finalPortNewReplicaSet> to the final port for the new replica set. 自動復元の場合は、以前に指定した<ephemeralPort>とは異なるポートを指定する必要があります。

新しいレプリカセットのすべてのノードをmembers配列に含めて構成していることを確認します。

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>:<finalPortNewReplicaSet>"
9 },
10 {
11 . . .
12 },
13 . . .
14 ],
15 "settings" : {
16
17 }
18})

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

{ "acknowledged" : true, "insertedId" : "<yourReplicaSetName>" }
5

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

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

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

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

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を使用して復元します。

  • MongoDB Ops Managerに自動復元を実行させます。

この問題は、MongoDB 4.4以降のスナップショットには適用されません。

1

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

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

次のコマンドを使用してmongodを起動します。 このアクションにより、 mongod状態と oplog が最大Restore timestampまで調整されます。 パスによっては、 mongodバイナリへのパスを指定する必要がある場合があります。

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

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

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

このステップは条件付きです。 ポイントインタイム復元が必要な場合は、それを実行します。

この手順では、レプリカセットのターゲット インスタンスで MongoDB バックアップ復元ユーティリティをダウンロードして実行し、 インスタンスを停止します。

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

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

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

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

    警告

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

  3. ターゲット ホストで MongoDB バックアップ復元ユーティリティを実行します。 レプリカセットに対してそれを 1 回実行します。

    重要

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

    MongoDB Ops Managermongodb-backup-restore-utilでは、Run Binary with PIT Options の下の復元パネルで復元に適したオプションが表示されます。

    MongoDB Ops Managerアプリケーションで提供される mongodb-backup-restore-util コマンドをコピーする必要があります。

    ./mongodb-backup-restore-util --https --host <targetHost> \
    --port <ephemeralPort> \
    --opStart <opLogStartTimeStamp> \
    --opEnd <opLogEndTimeStamp> \
    --logFile <logPath> \
    --oplogSourceAddr <oplogSourceAddr> \
    --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 アドレスを指定します。MongoDB Ops Manager アプリケーションで提供されるmongodb-backup-restore-utilコマンドをコピーした場合、このフィールドは事前構成されています。
    --port
    必須
    oplog を適用するmongod を提供するホストのエフェメラル ポートを指定します。
    --opStart
    必須

    復元に含める最初の oplog エントリの BSON タイムスタンプ を指定します。この情報は、ダウンロードされたスナップショットを含む restoreInfo.txt ファイルの「Last oplog Applied」エントリに表示されます。

    この値は--opEnd値以下である必要があります。

    --opEnd
    必須

    復元に含める最後の oplog エントリの BSON タイムスタンプ を指定します。

    この値は、oplog の終了よりも大きくすることはできません。

    --logFile
    任意
    MBRUログが書き込まれるファイル名を含むパスを指定します。
    --oplogSourceAddr
    必須
    MongoDB Ops Manager リソース エンドポイントのURLを指定します。
    --apiKey
    必須
    MongoDB Ops 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)を指定します。

    --sslが設定されている場合は必須です。

    --sslRequireValidServerCertificates
    任意
    ターゲット MongoDB プロセスが提示する証明書をツールが検証する必要があるかどうかを示すフラグを設定します。
    --sslServerClientCertificate
    任意
    MongoDB Ops Managerホストへの接続に使用するクライアント証明書ファイルへの絶対パスを指定します。
    --sslServerClientCertificatePassword
    条件付き

    MongoDB Ops Managerホストへの接続に使用するクライアント証明書ファイル パスワードへの絶対パスを指定します。

    --sslServerClientCertificateが設定され、その証明書が暗号化されている場合は必須です。

    --sslRequireValidMMSBackupServerCertificate
    任意
    MongoDB Ops Manager ホストに接続するときに有効な証明書が必要かどうかを示すフラグを設定します。 デフォルト値はtrueです。
    --sslTrustedMMSBackupServerCertificate
    任意

    ホストの PEM MongoDB Ops Manager形式で、信頼できる証明機関証明書への絶対パスを指定します。このフラグが提供されない場合は、システムの認証局が使用されます。

    MongoDB Ops Managerが自己署名SSL証明書を使用している場合は、この設定が必要です。

    --httpProxy
    任意
    ツールが使用できる HTTP プロキシ サーバーの URL を指定します。

    は、 MongoDB Ops Managerアプリケーションで提供される mongodb-backup-restore-util コマンドをコピーした場合、このフィールドが事前構成されているということを意味します。

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

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

次のコマンドを使用してmongodを起動し、これらのパラメータを指定します。

  • <bind_ip> レプリカセット構成で指定したこのレプリカセット メンバーを提供するホストに接続します。

  • <port> <ephemeralPort>一時的なスタンドアロン インスタンスを起動したときに指定した <一時停止:

このアクションは、MongoDB バックアップ復元ユーティリティを実行したときに挿入された oplog を最新のエントリまで再生します。

mongod --dbpath </path/to/datafiles> \
--port <ephemeralPort> \
--bind_ip <host-serving-this-replica-set-member>
--setParameter recoverFromOplogAsStandalone=true
--setParameter takeUnstableCheckpointOnShutdown=true
--setParameter startupRecoveryForRestore=true

この手順を完了すると、実際の復元プロセスが完了します。

3

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

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

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

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

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
2

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

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

戻る

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