オンプレミスのMongoDB配置から Atlas へのデータの移行には、さまざまな方法があります。 Atlas ライブ移行は、可能な場合は Atlas ライブ移行を使用することをお勧めします。これは、ダウンタイムが最小限で多くのタスクを自動化するためですが、データベース移行に固有のおよび複雑さがある他のツールを使用することもできます。
ライブ移行の概要
Atlas ライブ移行、オンプレミスのMongoDBデータベースから Atlas へのデータの移動が自動化されます。 Atlas ライブ移行には、次の機能が含まれています。
移行ホストは常に Atlas クラスターへのトラフィックを暗号化します。 Atlas ノード間のトラフィックは常に暗号化され、この機能を無効にすることはできません。特定のロールベース アクセス制御
backupreadAnyDatabase(RBAC)データベースロール（ 、 、またはclusterMonitorなど）と Atlas プロジェクト オーナーのみが ライブ移行を開始できます。ユーザーは SCRAM-SHA-1 または SCRAM-SHA-256 を使用してクラスターを認証します。ライブ移行により、ほとんどのタスクが自動化されます。フルマネージド「プル」メソッドの場合、ライブ移行はキー メトリクスをモニターし、移行サーバーをプロビジョニングし、移行コマンドの厳密なシーケンスを実行します。さらに、移行する Atlas 宛先クラスター層構成を選択することもできます。
詳細な手順は、宛先クラスターを増やすコストを管理するのに役立ちます。推奨事項には、適切なクラスター サイズと一時的なスケーリング、その後に移行後に最適なレベルにサイズ変更することが含まれます。
ライブ移行ではバックグラウンドで mongosync が使用されるため、データの並列コピーによる高速カットオーバーが容易になります。プロセスは、継続的なデータ同期と最終的なカットオーバーのフェーズを使用して、一時的なネットワークの中断とクラスターの選挙を管理し、最小限のダウンタイムを実現します。再試行メカニズムと移行前の検証により、中断に対する回復力が高まります。
リアルタイムのステータス更新と通知 で移行を監視します。
ライブ移行メソッド
ライブ移行サーバーを使用して Atlas にデータをプルすることができます。プル型のライブ移行メソッドでは、特定のMongoDBバージョン間の移行パスがサポートされています。詳細については、 サポートされている移行パス を参照してください。サポートされていないバージョンのMongoDBを使用しているデータベースからデータを移行するには、「 レガシー移行 」または「 手動移行メソッド 」を参照してください。
Atlas にデータを取得します。 Atlas はソースMongoDBデプロイからデータをプルするため、配置のファイアウォールを介してソース配置にアクセスする必要があります。クラスターが完全に同期されたら、ソース上で書込み操作を停止するカットオーバーのプロセスに従い、アプリケーションを Atlas クラスターにリダイレクトして再起動する必要があります。次の考慮事項が適用されます。
Cloud Managerまたは Ops Manager によって監視されていない配置に最適です。
ライブ移行サーバーからの受信アクセスを可能にするには、ソースデータベースがパブリックにアクセスできる必要があります。
ソースクラスターまたは宛先クラスターのいずれに対してもVPCピアリング または プライベートエンドポイント はサポートされていません。
ソースクラスターと宛先クラスターのトポロジーは一致している必要があります。例、 はどちらも同じ数のシャードを持つレプリカセットまたはシャーディングされたクラスターである必要があります。
カットオーバー中に書き込みを停止し、新しい接続文字列でアプリケーションを再起動するために、カットオーバー中に最小限のダウンタイムを計画します。移行プロセスは宛先クラスターで CPU 集中型であり、大容量のネットワーク帯域幅が必要です。
スムーズな移行プロセスを確保するには、ソースクラスターのoplogサイズが移行期間全体をカバーするのに十分であることを確認してください。ソースクラスターの場合、ライブ移行のラグウィンドウはoplogレプリケーションラグウィンドウの範囲内に収まる必要があります。この要件は、最小oplog ウィンドウを増やすか、固定oplogサイズを増やすことで満たできます。 MongoDBでは、宛先クラスターには、移行期間中にソースクラスターよりも少なくとも 2 階層上の宛先クラスター層を選択することをお勧めします。宛先クラスターでストレージのオートスケーリングが無効になっている場合は、宛先クラスターのoplogサイズを十分に大きい固定値に増やします。宛先クラスターでストレージのオートスケーリングが有効になっている場合は、宛先クラスターに十分な大きさの最小oplog ウィンドウを設定します。詳細については、「 Oplog の要件 」を参照してください。
完全な移行の推奨事項と手順については、「 Atlas へのクラスターのライブ移行（プル） 」を参照してください。
移行の監視
進行中の移行と過去の移行の両方を確認するには、Atlas の Migration Hub ページに移動します。
各移行プロセスをクリックすると、初期データのコピー時間の推定や包括的な進行状況レポートなどの詳細情報が表示されます。クラスター カードを使用して、移行を作成、カットオーバー、またはキャンセルします。
詳細については、「 移行の監視 」を参照してください。
手動移行メソッド
Atlas ライブ移行が移行要件の制約を満たせない場合は、Atlas 外で実行する次のいずれかのツールを使用して、既存のMongoDBデプロイ、JSON、または CSV ファイルのデータを Atlas に取り込むことができます。
ツール | 説明 |
|---|---|
mongosync バイナリは、Atlas ライブ移行で使用されるプライマリ プロセスです。スタンドアロンの | |
既存のレプリカセットまたはアプリケーションをシャットダウンせずに、 MongoDBレプリカセットから Atlas クラスターに移行します。 mongomirror はユーザーとロール データをインポートしたり、 | |
既存のMongoDBデプロイの mongodump から取得された データバックアップダンプを使用して Atlas クラスターをシードします。 | |
または | |
GUI を使用して、 または ファイルから |
Atlas クラスターのバックアップデータから別の Atlas クラスターへの復元も可能です。詳細については、「 クラスターの復元 」を参照してください。
Atlas VNet ピアリングまたは Private Link 構成のいずれかを使用する必要がある場合は、 サードパーティからそのソースクラスターへの直接接続を許可しないでください 、またはソースをまだ持っていない、またはインポートしたくない場合は、 ソースクラスターでは、Cloud Managerの mongosync アプローチを使用スタンドアロンMongoDBを推奨します。
移行するデータセットが比較的小さく、（300 GB未満）、アプリケーションのダウンタイムを長期間にわたって許容できる場合は、 MongoDBでは mongodump と mongorestore のアプローチを推奨します。
移行するデータセットが比較的小さく（300 GB未満）、インデックスに関する懸念なしに、アプリケーションのダウンタイムを長期間にわたって許容できる場合には、 MongoDB はmongoexport と mongoimport のアプローチを推奨します。
カットオーバー
移行が「カットオーバーの準備ができています」ステータスに達したら、クラスター カードで Cutover on target cluster をクリックし、次に Prepare to Cutover をクリックして、カットオーバー プロセスを開始します。カットオーバーが正常に完了したら、アプリケーションを再構成して新しい宛先クラスターを点ようにします。
詳細については、「 移行の監視 」を参照してください。
次のステップ
Atlas の組織、プロジェクト、クラスターに関する ガイダンス ページで、Atlas エンタープライズプロパティのビルド ブロックの詳細を学習するか、左側のナビゲーションを使用して各データベース フレームワーク ピリオドの機能とベストプラクティスを見つけます。