この手順では、MongoDB データを取得し、そのデータを新しい レプリカセット に復元するプロセスについて説明します。このアプローチは、本番環境のバックアップから、または障害復旧の一環としてテスト導入を行う場合に使用します。
重要
You can also use mongorestore to restore database files using data created with mongodump. See Back Up and Restore with MongoDB Tools for more information.
Considerations
バックアップはデータベースの現在の状態のスナップショットを提供します。バックアップから復元する場合、復元されたデータベースにはバックアップ作成後に行われた変更は含まれないため、データが失われる可能性があります。
単一ノード レプリカセットへのデータベースの復元
MongoDB データベースファイルのバックアップを取得します。
バックアップ ファイルは、ファイル システムのスナップショットから来る場合があります。MongoDB Cloud Manager は、保存されたスナップショットおよびポイントインタイム スナップショット用の MongoDB データベース ファイルを生成します。MongoDB Enterprise Advanced で利用可能なオンプレミス ソリューションである Ops Managerについては、Ops Manager バックアップの概要もご覧ください。
- 暗号化されたストレージ エンジンに関する考慮事項
AES256-GCM暗号化モードを使用する暗号化ストレージ エンジンの場合、AES256-GCMはすべてのプロセスについて、キーと一意のカウンター ブロック値を使用することを求めます。AES256-GCM暗号で構成されたストレージ エンジンの場合:- ホット バックアップからの復元
mongodが を実行中いる間に「ホット」バックアップで取得したファイルから復元すると、 MongoDB はスタートアップ時に「汚染された」キーを検出し、データベースキーを自動的にロールオーバーして、IV（Initialization Vector: 初期化ベクトル）の再利用を回避します。
- コールド バックアップからの復元
ただし、
mongodがを実行中いないときに「コールド」バックアップで取得したファイルから復元すると、 MongoDB はスタートアップ時に「汚染された」キーを検出せず、 IV の再利用によって機密性と整合性の保証が無効になります。コールド ファイルシステム スナップショットから復元した後にキーが再利用されるのを回避するため、 MongoDB に新しいコマンドライン オプション
--eseDatabaseKeyRolloverが追加されました。--eseDatabaseKeyRolloverオプションを使用して起動すると、mongodインスタンスはAES256-GCM暗号で構成されたデータベースキーをロールオーバーして終了します。
local データベースがバックアップに存在する場合は削除します。
ファイルシステムのバックアップ（または local データベースを含む任意のバックアップ）から復元する場合は、 local データベースを削除します。
バックアップのデータファイルをデータ パスとして使用して、スタンドアロンの mongod を起動します。
また、スナップショットの作成時に使用したのと同じ起動オプションを指定する必要があります。
mongod --dbpath /data/db <startup options>
local データベースを削除します。
Connect mongosh to the mongod instance and drop the local database.
use local db.dropDatabase()
スタンドアロンをシャットダウンします。
新しい単一ノード レプリカセットを開始します。
新しい単一ノードのレプリカセットとして mongod インスタンスを起動します。--dbpath オプションでバックアップ データ ファイルへのパスを指定し、 --replSet オプションでレプリカセット名を指定します。 コンフィギュレーションサーバー レプリカセット（CSRS）の場合は、 --configsvr オプションを含めます。配置に適したその他のオプションを含めます。
また、スナップショットの作成時に使用したのと同じ起動オプションを指定する必要があります。
注意
レプリカセット メンバーが異なるホスト上で実行されている場合、またはリモート クライアントをインスタンスに接続する場合は、 net.bindIp設定（または--bind_ip ）を指定する必要があります。
警告
インスタンスをパブリックにアクセス可能な IP アドレスにバインドする前に、クラスターを不正アクセスから保護する必要があります。 セキュリティ推奨事項の完全なリストについては、「自己管理型配置のセキュリティ チェックリスト」を参照してください。 最低限、認証を有効化し、ネットワーク インフラストラクチャの強化 を検討してください。
mongod --dbpath /data/db --replSet <replName> <startup options>
注意
すべての MongoDB コレクションはデフォルトで UUID を持ちます。MongoDB がコレクションを復元する場合、復元されたコレクションは元の UUID を保持します。UUID がないコレクションを復元する場合、MongoDB は復元されたコレクションのために UUID を生成します。
コレクション UUID について詳しくは、「コレクション」を参照してください。
Connect mongosh to the mongod instance.
From the same machine where one of the mongod is running (in this tutorial, mongodb0.example.net), start mongosh. To connect to the mongod listening to localhost on the default port of 27017, simply issue:
mongosh
Depending on your path, you may need to specify the path to the mongosh binary.
If your mongod is not running on the default port, specify the --port option for mongosh.
新しいレプリカセットを開始します。
rs.initiate() をレプリカセットの 1 人のメンバーのみに使用します。
rs.initiate( { _id : <replName>, members: [ { _id : 0, host : <host:port> } ] })
MongoDB は、現在のメンバーで構成され、デフォルトのレプリカセット設定を使用するセットを開始します。
レプリカセットへのメンバーの追加
MongoDB には、レプリカセットのセカンダリ メンバーを復元するための 2 つのオプションがあります。
最初の同期を許可してデータを自動的に分散します。
注意
データベースが大きい場合、最初の同期が完了するまでに長い時間がかかることがあります。大規模なデータベースの場合は、データベース ファイルを各ホストにコピーすることをお勧めします。
データベース ファイルのコピーと mongod インスタンスの再起動
次の一連の操作を使用して、MongoDB データファイルを直接コピーして、復元されたデータをレプリカセットの追加メンバーに「シード」します。
復元した mongod インスタンスをシャットダウンします。
確実にクリーンなシャットダウンを行うには、 --shutdown または db.shutdownServer() を使用します。
復元した mongod インスタンスを起動します。
セカンダリをレプリカセットに追加します。
In a mongosh session that is connected to the primary, add the secondaries to the replica set using the rs.add() method. See Deploy a Self-Managed Replica Set for more information about deploying a replica set.
最初の同期を使用したセカンダリの更新
次の一連の操作を使用して、デフォルトの最初の同期操作を使用して、レプリカセットの追加メンバーに復元されたデータを「シード」します。
レプリカセット メンバーになる可能性のある各メンバーのデータディレクトリを空にします。
例えば、レプリカセット メンバーの storage.dbPath または --dbpath が /data/db の場合、ディレクトリが存在し、さらには空であることを確認する必要があります。