MongoDB バックアップから自己管理型レプリカセットの復元
この手順では、MongoDB データを取得し、そのデータを新しいレプリカセットに復元するプロセスについて説明します。 このアプローチは、本番環境のバックアップから、または障害復旧の一環としてテスト導入を行う場合に使用します。
重要
また、 mongorestoreは、 mongodumpで作成されたデータを使用するデータベースのファイルを復元する目的でも使用できます。 詳細については、「 MongoDB ツールを使用した自己管理型配置のバックアップと復元」を参照してください。
単一ノード レプリカセットへのデータベースの復元
MongoDB データベースファイルのバックアップを取得します。
バックアップファイルはファイルシステムのスナップショットから来る場合があります。MongoDB Cloud Manager は 保存されたスナップショットおよびポイントインタイムスナップショット用の MongoDB データベースファイルを生成します。MongoDB Enterprise Advanced で利用可能なオンプレミス ソリューションである Ops Managerについては、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 の場合、ディレクトリが存在し、さらには空であることを確認する必要があります。