オンプレミスの MongoDB 配置から Atlas へデータを移行するには、さまざまな方法の中から 1 つを使用できます。可能な場合は、Atlas ライブ移行を使用することをお勧めします。これは、多くのタスクを自動化し、ダウンタイムを最小限に抑えるためです。ただし、データベース移行に固有の多様性と複雑さに対応する他のツールを使用することもできます。
ライブ移行の概要
Atlas ライブ移行は、オンプレミスの MongoDB データベースから Atlas へのデータ移動を自動化します。Atlas ライブ移行には、以下の機能が含まれています。
移行ホストは常に Atlas クラスターへのトラフィックを暗号化します。Atlas ノード間のトラフィックは常に暗号化され、この機能を無効にすることはできません。特定のロールベースアクセス制御（RBAC）データベースロール（例えば、
backup、readAnyDatabase、または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 で取得した | |
| |
GUI を使用して、 |
Atlas クラスターのバックアップデータから別の Atlas クラスターに復元することも可能です。詳細については、「クラスターの復元」を参照してください。
Atlas VNet ピアリングまたは Private Link 構成のいずれかを使用する必要がある場合、サードパーティからソースクラスターへの直接接続を許可したくない場合、または Ops Manager や Cloud Manager にソースクラスターをまだ持っていない、またはインポートしたくない場合、MongoDB はスタンドアロンの mongosync アプローチを推奨します。
もし比較的小規模なデータセット（300 GB 未満）を移行し、長期間のアプリケーションのダウンタイムを許容できる場合、MongoDB では mongodump と mongorestore を使用する方法を推奨します。
比較的小規模なデータセット（300 GB 未満）を移行する場合で、インデックスに関する懸念がなく、アプリケーションの長時間のダウンタイムを許容できるのであれば、MongoDB は mongoexport とmongoimport を使用する方法を推奨します。
カットオーバー
移行が「カットオーバー準備完了」ステータスに達したら、クラスターカードの Cutover on target cluster をクリックし、その後Prepare to Cutover をクリックして、カットオーバープロセスを開始してください。カットオーバーが成功したら、新しい宛先クラスターを指すようにアプリケーションを再構成してください。
詳細については、「移行のモニター」を参照してください。
次のステップ
「Atlas の組織、プロジェクト、クラスターに関するガイダンス」ページを参照して、Atlas エンタープライズ エステートの構成要素について学ぶか、左側のナビゲーションを使用して各 Well-Architected Framework の柱の機能とベストプラクティスをご覧ください。