MongoDB バックアップから自己管理型レプリカセットの復元
この手順では、MongoDB データを取得し、そのデータを新しいレプリカセットに復元するプロセスについて説明します。 このアプローチは、本番環境のバックアップから、または障害復旧の一環としてテスト導入を行う場合に使用します。
重要
また、 mongorestoreは、 mongodumpで作成されたデータを使用するデータベースのファイルを復元する目的でも使用できます。 詳細については、「 MongoDB ツールを使用した自己管理型配置のバックアップと復元」を参照してください。
単一ノード レプリカセットへのデータベースの復元
MongoDB データベースファイルのバックアップを取得します。
バックアップ ファイルは、ファイル システムのスナップショットから取得される場合があります。 MongoDB Cloud Managerは、保存済みスナップショットとポイントインタイム スナップショット用の MongoDB データベース ファイルを生成します。 MongoDB Ops Managerで利用可能なオンプレミス ソリューションMongoDB Enterprise AdvancedMongoDB Ops Manager ある MongoDB Ops Manager については、「 バックアップの概要 」も参照してください。
- 暗号化されたストレージ エンジンに関する考慮事項
AES256-GCM暗号化モードを使用する暗号化されたストレージ エンジンの場合、AES256-GCMでは、すべてのプロセスが、キーとともに一意のカウンター ブロック値を使用する必要があります。AES256-GCM暗号で構成された暗号化されたストレージ エンジンの場合は、 となります。- ホット バックアップからの復元
- バージョン 4.2 以降、「ホット」バックアップ（
mongodが実行されている状態）で取得したファイルからの復元では、MongoDB が起動時に「汚染された」キーを検出し、データベース キーを自動的にロールオーバーして、IV（Initialization Vector: 初期化ベクトル）の再利用を回避できるようになりました。
- コールド バックアップからの復元
ただし、「コールド」バックアップ（
mongodが実行されていない状態）で取得したファイルからの復元では、MongoDB が起動時に「汚染された」キーを検出できず、IV を再利用すると、機密性と整合性における保証が無効になります。バージョン 4.2 以降では、コールド ファイルシステム スナップショットから復元した後にキーが再利用されるのを回避するため、MongoDB に新しいコマンド ライン オプション
--eseDatabaseKeyRolloverが追加されました。--eseDatabaseKeyRolloverオプションを使用して起動すると、mongodインスタンスはAES256-GCM暗号で構成されたデータベース キーをロールオーバーして終了します。
localデータベースがバックアップに存在する場合は、それを削除します。
ファイルシステムのバックアップ（または local データベースを含む任意のバックアップ）から復元する場合は、 local データベースを削除します。
mongodバックアップのデータファイルをデータパスとして使用して、スタンドアロン を起動します。
また、スナップショットの作成時に使用したのと同じ起動オプションを指定する必要があります。
mongod --dbpath /data/db <startup options>
localデータベースを削除します。
mongosh を mongod インスタンスに接続し、local データベースを削除します。
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 について詳しくは、「コレクション」を参照してください。
新しいレプリカセットを開始します。
rs.initiate() をレプリカセットの 1 人のメンバーのみに使用します。
rs.initiate( { _id : <replName>, members: [ { _id : 0, host : <host:port> } ] })
MongoDB は、現在のメンバーで構成され、デフォルトのレプリカセット設定を使用するセットを開始します。
レプリカセットへのメンバーの追加
MongoDB には、レプリカセットのセカンダリ メンバーを復元するための 2 つのオプションがあります。
最初の同期を許可してデータを自動的に分散します。
注意
データベースが大きい場合、最初の同期が完了するまでに長い時間がかかることがあります。大規模なデータベースの場合は、データベース ファイルを各ホストにコピーすることをお勧めします。
データベース ファイルのコピーとmongod インスタンスの再起動
次の一連の操作を使用して、MongoDB データファイルを直接コピーして、復元されたデータをレプリカセットの追加メンバーに「シード」します。
復元したmongod インスタンスをシャットダウンします。
確実にクリーンなシャットダウンを行うには、 --shutdown または db.shutdownServer() を使用します。
復元したmongod インスタンスを起動します。
セカンダリをレプリカセットに追加します。
プライマリ mongoshに接続されている セッションで、rs.add() メソッドを使用してレプリカセットに セカンダリ を追加します。レプリカセットの配置の詳細については、「自己管理型レプリカセットの配置 」を参照してください。
最初の同期を使用したセカンダリの更新
次の一連の操作を使用して、デフォルトの最初の同期操作を使用して、レプリカセットの追加メンバーに復元されたデータを「シード」します。
レプリカセット メンバーになる可能性のある各メンバーのデータディレクトリを空にします。
例えば、レプリカセット メンバーの storage.dbPath または --dbpath が /data/db の場合、ディレクトリが存在し、さらには空であることを確認する必要があります。