バックアップからレプリカセットを復元すると、 MongoDB Ops Managerは選択した復元ポイントの復元ファイルを提供します。 復元プロセスの詳細については、「 復元の概要 」を参照してください。
Considerations
BinData
BSONサブタイプへの変更を確認する
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 の起動オプション
暗号化(スナップショットで暗号化が有効になっている場合にのみ表示されます)
マスターキー UUID (スナップショットで暗号化が有効になっている場合にのみ表示されます)
暗号化されたバックアップから復元する場合は、このマスター キーに対して証明書がプロビジョニングされている必要があります。
バックアップに関する考慮事項
すべての FCVデータベースは、適切なバックアップに関する考慮事項を満たしている必要があります。
前提条件
手動復元を実行するには、 MongoDB Ops Managerの バックアップ管理者 ロールが必要です。
暗号化されたバックアップから復元するには、バックアップの暗号化に使用されるのと同じマスター キーと、バックアップデーモンホスト上のものと同じ証明書、またはKMIPホストからそのキーでプロビジョニングされた新しい証明書が必要です。
スナップショットが暗号化されている場合、復元パネルには KMIP マスター キー ID と KMIP サーバー情報が表示されます。 また、スナップショット自体とrestoreInfo.txt
ファイルを表示する際にも、 情報を見つけることができます。
復元中のクライアントリクエスト
復元中に MongoDB 配置がクライアント リクエストを受信しないことを確認する必要があります。 次のいずれかを行う必要があります。
新しいホスト名を持つ新しいシステムに復元し、新しい配置が実行中以降にアプリケーション コードを再構成する。または、
データの復元中に MongoDB 配置がクライアント リクエストを受信しないことを確認します。
スナップショットの復元
重要
AES256-GCM で暗号化されたスナップショット復元後のマスター キー ローテーション
がMongoDB Ops Manager AES256-GCM を使用して 暗号化したスナップショット を復元する場合は、復元の完了後 に マスターキーをローテーション します 。
自動復元
MongoDB Ops Managerがスナップショットを自動的に復元するようにするには、次の手順に従います。
復元ポイントを選択します。
バックアップを復元するポイントを選択します。
復元タイプ説明アクション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
スナップショットを復元するクラスターを選択します。
MongoDB Ops Managerは、ターゲット レプリカセットを管理する必要があります。
警告:オートメーションにより、クラスターから既存のデータがすべて削除されます。 既存のクラスターのすべてのバックアップ データとスナップショットが保持されます。
[Restore] をクリックします。
MongoDB Ops Managerは、復元に必要なストレージ領域の量を示します。
手動復元
警告
自動復元を検討する
この手順には、多数のステップが含まれます。 これらの手順の一部は、セキュリティに重大な影響を与えます。 MongoDB Ops Managerが管理していない配置に復元する必要がない場合は、自動復元を検討してください。
スナップショットの取得
[0} Continuous Backupをクリックし、 Overviewタブをクリックします。
復元ポイントを選択します。
バックアップを復元するポイントを選択します。
復元タイプ説明アクション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] をクリックします。
2FAを使用する場合、 MongoDB Ops Managerは 2FA コードの入力を要求します。 2 FA コードを入力し、 Finalize Requestをクリックします。
Retrieve the Snapshots.
MongoDB Ops Managerはスナップショットへのリンクを作成します。 デフォルトでは、これらのリンクは 1 時間利用でき、使用できるのは 1 回だけです。
スナップショットをダウンロードするには:
復元パネルを閉じた場合は、 Continuous Backupをクリックし、次に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
データベースから削除する。
手動復元を実行するには、 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 })
新しいレプリカセット構成の追加。
次のドキュメントをlocal
データベースのsystem.replset
コレクションに挿入します。 次の変数を変更します。
<replaceMeWithTheReplicaSetName>
に、レプリカセットの名前を設定します。 この名前は古い名前と同じである必要はありません。<host>
このレプリカセット ノードを提供するホストに渡す追加オプション。<finalPortNewReplicaSet>
to the final port for the new replica set. 自動復元の場合は、以前に指定した<ephemeralPort>
とは異なるポートを指定する必要があります。
新しいレプリカセットのすべてのノードをmembers
配列に含めて構成していることを確認します。
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>:<finalPortNewReplicaSet>" 9 }, 10 { 11 . . . 12 }, 13 . . . 14 ], 15 "settings" : { 16 17 } 18 })
成功した応答は次のようになります。
{ "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を使用して復元します。
MongoDB Ops Managerに自動復元を実行させます。
この問題は、MongoDB 4.4以降のスナップショットには適用されません。
インスタンスの管理
一時スタンドアロン インスタンスを停止します。
パスによっては、 mongosh
へのパスを指定する必要がある場合があります。 実行:
mongosh --port <ephemeralPort> \ --eval "db.getSiblingDB('admin').shutdownServer()"
エフェメラル ポートの一時インスタンスを停止します。
パスによっては、 mongosh
へのパスを指定する必要がある場合があります。 実行:
mongosh --port <ephemeralPort> \ --eval "db.getSiblingDB('admin').shutdownServer()"
ポイントインタイム スナップショットの復元
(ポイントインタイム復元のみ) MongoDB バックアップ復元ユーティリティを実行します。
このステップは条件付きです。 ポイントインタイム復元が必要な場合は、それを実行します。
この手順では、レプリカセットのターゲット インスタンスで MongoDB バックアップ復元ユーティリティをダウンロードして実行し、 インスタンスを停止します。
MongoDB バックアップ復元ユーティリティをホストにダウンロードします。
復元パネルを閉じた場合は、 Continuous Backup in Deployment 、 More 、 Download MongoDB Backup Restore Utilityの順にクリックします。
抽出したスナップショット ディレクトリをデータディレクトリとして使用し、認証を有効にせずに
mongod
インスタンスを起動します。 パスによっては、mongod
バイナリへのパスを指定する必要がある場合があります。mongod --port <ephemeralPort> \ --dbpath </path/to/datafiles> \ --setParameter ttlMonitorEnabled=false \ --bind_ip <hostname_or_IP> 警告
MongoDB バックアップ復元ユーティリティは認証をサポートしていないため、認証を使用してこの一時データベースを起動することはできません。
ターゲット ホストで MongoDB バックアップ復元ユーティリティを実行します。 レプリカセットに対してそれを 1 回実行します。
重要
事前構成された mongodb-backup-restore-tools コマンド
MongoDB Ops Manager
mongodb-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
必須
--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
任意
--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
コマンドをコピーした場合、このフィールドが事前構成されているということを意味します。インスタンスで
mongod
を停止します。 パスによっては、mongosh
へのパスを指定する必要がある場合があります。 実行:mongosh --port <ephemeralPort> \ --eval "db.getSiblingDB('admin').shutdownServer()"
(ポイントインタイム復元のみ) oplog を回復するには、 インスタンスを再起動します。
次のコマンドを使用して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
この手順を完了すると、実際の復元プロセスが完了します。
(ポイントインタイム復元のみ) スタンドアロン インスタンスを停止します。
パスによっては、 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 Ops Manager ます。
Deploymentページで、 Addをクリックし、 Existing MongoDB Deploymentを選択して、クラスターへのAutomationの追加に進みます。