Docs Menu
Docs Home
/
MongoDB Atlas
/ / /

レプリカセットの Atlas へのライブ移行(プル)( MongoDB 6.0.17以前)

項目一覧

  • 制限事項
  • 必要なアクセス権
  • 前提条件
  • Considerations
  • お使いのクラスターを移行する
  • 移行サポート

重要

サーバーレスインスタンスで使用できない機能

サーバーレスインスタンスは現時点ではこの機能をサポートしていません。詳細については、 サーバーレスインスタンスの制限を参照してください。

ソースクラスターと宛先クラスターがMongoDB6.0.17 + または7.0.13 + を実行中している場合は、この手順を使用して Atlas にライブ移行できます。

Atlas は、レガシーライブ移行プロセスを使用してソースレプリカセットを Atlas クラスターにプルすることができます。 Atlas は、アプリケーションが宛先の Atlas クラスターに切り替わるまで、ソースクラスターから宛先クラスターに同期します。

次の手順のカットオ―バーのステップに到達したら、ソースクラスターへの書き込みを停止します。アプリケーション インスタンスを停止してから、Atlas クラスターを向くように設定し、再起動します。

  • M0(無料階層)または 共有クラスターをレガシーライブ移行(プル)のソースまたは宛先ターゲットとして選択することはできません。M2/M5 M0(無料階層)またはM2/M5 共有クラスターから有料クラスターにデータを移行するには、クラスター層とタイプを変更します。

  • レガシーライブ移行(プル)では、ソースまたは宛先クラスターのバージョンとしてMongoDB 8.0 または Rapid Release をサポートしていません。

  • シャーディングされたクラスターでは、レガシーライブ移行(プル)はサポートされていません。

    MongoDBバージョン6.0.17 またはそれ以前のバージョンを実行するソースシャーディングされたクラスターをライブ移行するには、 はクラスターを6.0.17 + または7 にアップグレードします。0 。13 + から、このライブ移行手順を使用して、Atlas にそれをライブ移行します。

  • レガシーライブ移行(プル)では、ソースクラスターまたは宛先クラスターのいずれに対してもVPCピアリング または プライベートエンドポイント はサポートされていません。

  • 従来のライブ移行(プル)では、時系列コレクションを含むソースレプリカセットの移行はサポートされていません。

  • ライブ移行中は、Atlas はホスト アラートを無効にします。

データをライブ移行するには、Atlas への Project Owner アクセス権が必要です。

Organization Owner アクセス権を持つユーザーは、自分自身を Project Owner としてプロジェクトに追加する必要があります。

  • ライブ移行サービスにプライマリ ノードのホスト名を指定します。

  • MongoDB 4.4以前のバージョンから MongoDB 5.0以降のバージョンを実行する Atlas クラスターに移行する場合は、コレクションからgeoHaystack インデックスをすべて削除します。

  • クラスターが認証を使用して実行されている場合は、移行プロセスを実行するユーザーに次の権限を付与します。

    • ホスト上のすべてのデータベースとコレクションを読み取る。

    • プライマリ ノードの oplog に対する読み取りアクセス権。

ソースクラスター セキュリティの詳細については、こちらを参照してください。

重要

ソースクラスタの準備状況

スムーズなデータ移行を実現するには、ソースクラスターが本番クラスターの推奨事項をすべて満たしている必要があります。ライブ移行プロセスを開始する前に、操作チェックリストプロダクション ノートを確認してください。

Atlas ライブ移行(プル)では、次の移行パスがサポートされています。

Source Replica Set
MongoDB Version
Destination Atlas Replica Set
MongoDB Version

4.2

6.0

4.4

6.0

5.0

6.0

以下のコンポーネントのネットワーク権限を設定します。

ソースクラスターのファイアウォールはすべて、MongoDB ライブ移行サーバーからソースクラスターへのアクセスを許可する必要があります。

Atlas ライブ移行プロセスでは、MongoDB が制御するライブ移行サーバーを介してデータが転送されます。Atlas は、ライブ移行プロセス中に MongoDB ライブ移行サーバーの IP 範囲を提供します。これらの IP 範囲にソースクラスターへのアクセスを許可します。これにより、MongoDB ライブ移行サーバーがソースクラスターに接続できるようになります。

注意

組織の厳格なネットワーク要件により、MongoDB ライブ移行サーバーへの必要なネットワーク アクセスを有効にできない場合は、「コミュニティ配置の Atlas へのライブ移行」を参照してください。

Atlas では、プロジェクトのIP アクセス リストに追加されたホストからクラスターへの接続を許可します。アプリケーション ホストの IP アドレスまたは CIDR ブロックをプロジェクトの IP アクセス リストに追加します。これは、移行手順を開始する前に行ってください。

Atlas は、MongoDB 移行サーバーの IP アドレスをプロジェクトの IP アクセス リストに一時的に追加します。移行手順中は、このエントリを編集または削除することはできません。Atlas は手順が完了すると、このエントリを削除します。

Atlas IP アクセス リストにエントリを追加する方法については、「IP アクセス リスト エントリの設定」を参照してください。

プル型のライブ移行手順を開始する前に、Atlas はソースクラスターと宛先クラスターの検証チェックを実行します。

注意

レプリカセットの移行プロセスを実行するために、Atlas は指定されたホスト名に基づいてレプリカセットのホスト名を検出します。検出に失敗した場合、Atlas は指定された到達可能なホスト名を使用してレプリカセットを移行します。詳細については、「 ネットワーク アクセス 」を参照してください。

さまざまな組み込みロールによって、十分な権限が付与されます。以下に例を挙げます。

ソースクラスターの場合、ユーザーには readAnyDatabaseclusterMonitor、および backup ロールが必要です。

ライブ移行プロセスを実行するデータベースユーザーがこれらのロールを持っていることを確認するには、 admin データベースで db.getUser() コマンドを実行します。

use admin
db.getUser("admin")
{
"_id" : "admin.admin",
"user" : "admin",
"db" : "admin",
"roles" : [
{
"role" : "backup",
"db" : "admin"
},
{
"role" : "clusterMonitor",
"db" : "admin"
}
{
"role" : "readAnyDatabase",
"db" : "admin"
}
]
} ...

さらに、ソースクラスターのデータベースユーザーには、 admin データベース上の oplog を読み取るロールが必要です。詳細については、「Oplog アクセス」を参照してください。

ライブ移行手順でプロンプトが表示されたら、Atlas にユーザー名とパスワードを指定します。

Atlas は、認証を強制するソースクラスターへの接続には SCRAM のみサポートします。

Tip

移行時に認証情報を隠すには、ソースクラスターに移行に必要な最小限の権限を持つ一時ユーザーを追加し、移行プロセスが完了したらそのユーザーを削除することを検討してください。

ソースクラスターが接続に異なる認証メカニズムを使用する場合、 を使用してソースクラスターから宛先の Atlasmongomirror クラスターにデータを移行できます。

Atlas へのプル タイプのライブ移行は、ライブ移行を実行するサーバーをAtlas が管理し、ソースから宛先クラスターにデータを送信します。

MongoDB では、Atlas に送信されるデータの整合性と機密性を保護するために、次の措置を講じています。

  • MongoDB では、Atlas が管理するライブ移行サーバーと宛先クラスター間で転送されるデータは暗号化されます。ソースクラスターと Atlas が管理する移行サーバー間で転送されるデータの暗号化が必要な場合は、ソースクラスターで TLS を設定します。

  • MongoDB では、Atlas の他の部分へのアクセスが保護されるのと同様に、Atlas が管理する移行サーバー インスタンスへのアクセスが保護されます。

  • クリティカルなサービスの調査や復旧のために介入が必要となる稀なケースでは、MongoDB は最小権限の原則に準じ、クリティカルな問題を修復するために必要最小限の限られた時間だけ、少数の権限ユーザーのグループにお客様の Atlas クラスターへのアクセスを許可します。MongoDB では、これらのユーザーは Atlas クラスターにログインし、要塞ホスト経由で SSH 接続を確立するために MFA が必要です。この種の権限ユーザーにアクセス権を付与するには、MongoDB 上級管理職の承認が必要です。MongoDB では、他のいかなる MongoDB 担当者による、お客様の MongoDB Atlas クラスターへのアクセスは許可されていません。

  • MongoDB では、特権アクティビティでのみ特権ユーザー アカウントの使用が許可されます。 非特権アクティビティを実行するには、特権ユーザーは別のアカウントを使用する必要があります。 特権ユーザー アカウントでは、共有認証情報を使用できません。 特権ユーザー アカウントは、 Atlas セキュリティのホワイトペーパーのセクション4.3.3に記載されているパスワードの要件に従う必要があります。

  • Atlas では、権限ユーザーを含むすべての MongoDB 担当者による、お使いのクラスターへのアクセスを制限することができます。お客様がそのようなアクセス制限をすることを選択し、MongoDB がお問い合わせの問題を解決するためにアクセスが必要であると判断した場合、MongoDB はまずお客様へアクセス許可をリクエストする必要があります。そしてお客様は、最大 24 時間の権限ユーザーアクセスを一時的に復元するかどうかを決定できます。一時的な 24 時間のアクセス許可はいつでも取り消すことができます。この制限を有効にすると、お問い合わせの問題への対応とその解決にかかる時間が長くなり、その結果、Atlas クラスターの可用性に悪影響を及ぼす可能性があります。

  • MongoDB では、権限ユーザーのアクセス承認を四半期ごとに確認します。さらに MongoDB では、不要となった権限ユーザーのアクセス権を取り消します。権限ユーザーのロールが変更となったり、会社を退職した場合は、 24 時間以内にアクセス権を取り消します。また、MongoDB の担当者によるお客様の Atlas クラスターへのアクセスを記録し、タイムスタンプ、アクター、アクション、出力を含んだ監査ログを少なくとも 6 年間保持します。MongoDBは、自動レビューと手動レビューの組み合わせを使用して、これらの監査ログを精査します。

Atlas セキュリティの詳細については、 Atlas セキュリティのホワイトペーパーを参照してください。特に、「MongoDB Atlas クラスターへの MongoDB 担当者のアクセス」セクションを確認してください。

お使いの MongoDB 配置に、インデックス キー制限を超えるキーを持つインデックスが含まれている場合は、ライブ移行を開始する前に、インデックスを変更して、大きすぎるキーが含まれないようにします。

プル型のライブ移行中、ソースクラスターが自身のデータに対して TLS 暗号化を使用しない場合、ソースクラスターから Atlas へのトラフィックは暗号化されません。これが受け入れられるかどうかを、プル型のライブ移行手順を開始する前に判断してください。

Atlas は、いかなるユーザー データーまたはロール データも宛先クラスターに移行しません。

ソースクラスターが認証を使用しない場合、Atlas でユーザーを作成する必要があります。Atlas では認証無しの実行がサポートされないためです。

ソースクラスターが認証を強制する場合、アプリケーションが宛先の Atlas クラスターで使用する認証情報を再び作成する必要があります。Atlas ではユーザー認証に SCRAM が使用されます。詳細については、「データベースユーザーの設定」を参照してください。

宛先クラスターを構成する際には、次の点を考慮してください。

  • ライブ移行プロセスでは、MongoDB が管理するライブ移行サーバーを介してデータがストリーミング転送されます。各サーバーは、ソースクラスターに最も近いリージョンでホストされているインフラストラクチャ上で動作します。次のリージョンがご利用いただけます。

    ヨーロッパ
    • フランクフルト

    • アイルランド

    • London

    Americas
    • アメリカ東部

    • アメリカ西部

    APAC
    • ムンバイ

    • 香港

    • シドニー

    • Tokyo

  • Atlas の宛先クラスターには、アプリケーションサーバーまたはソースクラスターでホストされている配置と比較して、ネットワークレイテンシーが最も低いクラウドリージョンをお使いください。理想的なのは、アプリケーションのサーバーは、宛先の Atlas クラスターのプライマリ リージョンと同じリージョンのクラウドで実行されていることです。詳細については、「クラウドプロバイダー」を参照してください。

  • Atlas の宛先クラスターは、RAM、CPU、およびストレージの点でソースとなる配置と同じかそれを上回る必要があります。移行プロセスと予想されるワークロードの両方に対応できるように、適切なサイズの宛先クラスターをプロビジョニングするか、宛先クラスターをより処理能力、帯域幅、またはディスク IO のある階層にスケールアップします。

  • 移行のパフォーマンスを最大化するには、宛先クラスターに少なくとも 1 つの M40 クラスターを使用してください。大規模なデータセットを移行する場合は、6000 IOPS 以上のディスクを搭載した M80 クラスターを使用してください。

    移行プロセスの実行中に宛先 Atlas クラスターのサイズを一時的に増やすことも選択できます。

    アプリケーションのワークロードを Atlas のクラスターに移行したら、コストを最小限に抑えるために宛先クラスターのさらなるパフォーマンス調整とサイズ設定に関するサポートを受けるため、サポートにお問い合わせください 。

  • 予期しないサイズ変更を避けるため、宛先クラスターでオートスケーリングを無効にします。詳細については、「クラスターの管理」を参照してください。

  • oplog コレクションの無制限の増加を防ぎ、ライブ移行のラグ ウィンドウが oplog レプリケーション ラグ ウィンドウの範囲内に収まるようにするには、ライブ移行プロセスの実行中に十分な固定値の oplog サイズ を設定します。

    詳しくは以下を参照してください。

    これらの推奨事項に従っていてもパフォーマンスの問題が見られる場合は、サポートにお問い合わせください 。

  • 宛先 Atlas クラスターはレプリカセットである必要があります。

  • M0(無料階層)または M2/M5 共有階層クラスターをライブ移行の宛先クラスターとして選択することはできません。

  • Atlas ライブ移行の実行中は、featureCompatibilityVersion フラグを変更しないでください。

宛先クラスターでは、ライブ移行プロセスと重複しない名前空間で実行されうるワークロードを含め、いかなるワークロードも実行しないでください。このアクションにより、ライブ移行プロセス中に発生する可能性のあるロックの競合やパフォーマンスの低下を回避できます。

同じ宛先クラスターに対して、複数の移行を同時に実行しないでください。

ライブ移行プロセスの同期中は、アプリケーションの宛先クラスターへのカットオーバーのプロセスを開始しないでください。

Atlas は、ライブ移行中に宛先クラスターのオンデマンド クラウドバックアップのスナップショットの取得を停止します。このページに記載されているライブ移行手順のカットオーバーのステップが完了すると、Atlas はバックアップ ポリシーに基づいてクラウドバックアップのスナップショットの取得を再開します。

移行プロセスの実行中は、renameCollection コマンドの使用や、$out 集計ステージを含む集計パイプラインの実行など、名前空間の変更を行わないでください。

ライブ移行プロセスは、ソースクラスターまたは宛先クラスターで一時的にネットワークの中断が発生したり、選挙が行われても、移行が継続されるように最善を尽くします。ただし、これらのイベントによりライブ移行プロセスが失敗する可能性があります。ライブ移行プロセスが自動的に回復しない場合は、最初からやり直してください。

注意

ステージングと本番環境の移行

この手順を 2 回実行することを検討してください。まず、 Perform the Cutover ステップで停止する部分的な移行を実行します。これにより、最新の Atlas ベースのステージング クラスターが作成され、MongoDB 向けの Atlas クラスターをサポートする最新のドライバー バージョンを使用して、アプリケーションの動作とパフォーマンスをテストできます。

アプリケーションをテストした後、別の Atlas クラスターを使用して完全な移行手順を実行し、Atlas ベースの本番環境を作成します。

重要

ライブ移行プロセスの実行中は、レプリカセット ノードの削除やmongod のランタイム設定(featureCompatibilityVersion など)の変更など、ソースクラスター構成を変更しないでください。

ライブ移行手順を開始する前に、

  • 宛先クラスターがまだない場合は、新しい Atlas 配置を作成し、必要に応じて構成します。Atlas クラスターの作成に関する詳細なドキュメントについては、「クラスターの作成」を参照してください。

  • Atlas クラスターを配置した後に、アプリケーションを実行するすべてのクライアント ハードウェアからこのクラスターに接続できることを確認します。接続文字列のテストをすることによって、データ移行プロセスが最小限のダウンタイムで完了することを確認できます。

    1. まだインストールしていない場合は、代表のクライアント マシンに mongosh ダウンロードしてインストールします。

    2. Atlas UI から接続文字列を使用して宛先クラスターに接続します。詳細については、mongosh 経由で接続」を参照してください。

    宛先クラスターへの接続を確認したら、ライブ移行手順を開始します。

1
  1. 宛先の Atlas クラスターを選択します。

    宛先の Atlas クラスターに移動し、 をクリックします。 。 クラスター リストで、は、クラスター名の下にあります。 クラスターの詳細を表示すると、 は、画面の右側、Connect Configurationボタンと ボタンの横にあります。

  2. [Migrate Data to this Cluster] をクリックします。

  3. Atlas には、ライブ移行の進め方を示すウォークスルー画面が表示されます。このプロセスでは、ソースクラスターのデータが新しい宛先クラスターに同期されます。ウォークスルーを完了したら、お使いのアプリケーションが新しいクラスターに向くよう設定できます。

    移行を容易に行うために、ソースクラスターの以下の詳細を収集します。

    • ソースクラスターのプライマリノード のホスト名とポート。 Atlas は、デフォルトではソースクラスターのプライマリ メンバーにのみ接続します。 必要に応じて回復力を高め、フェイルオーバーを容易にするために、Atlas は他のソースクラスター ノードが公開されている DNS レコードを持つ場合、その IP アドレスを取得します。

    • ソースクラスターへの接続に使用するユーザー名とパスワード。

    • ソースクラスターがTLS/SSLを使用し、公開認証局(CA)を使用していない場合は、ソースクラスターのCAファイルを準備します。

    ウォークスルー画面に記載されている情報を準備し、I'm Ready To Migrate をクリックします。

  4. Atlas は、ソースクラスターに接続するために必要な情報を収集するためにウォークスルー画面を表示します。

    • Atlas では、ライブ移行を担う MongoDB ライブ移行サーバーの IP アドレスがウォークスルー画面の上部に表示されます。表示された IP アドレスへのアクセスを許可するように、ソースクラスターのファイアウォールを設定します。

    • 表示されたテキストボックスに、ソースクラスターのプライマリノードのホスト名とポートを入力します。たとえば、mongoPrimary.example.net:27017 と入力します。

    • ソースクラスターが認証を強制する場合は、表示されたテキストボックスにユーザー名とパスワードを入力します。

      Atlas ライブ移行に必要なユーザー権限に関するガイダンスについては、「ソースクラスターのセキュリティ」を参照してください。

    • ソース レプリカセットが TLS/SSL を使用しており、公開認証局(CA)を使用していない場合は、Is encryption in transit enabled? スイッチを切り替えて、ソースクラスターの CA ファイルの内容を表示されたテキストボックスにコピーします。

    • 移行プロセスを開始する前に、宛先レプリカセットのすべてのコレクションを削除する場合は、Clear any existing data on your destination cluster? のマークが付いたスイッチを Yes に切り替えます。

  5. Validate をクリックして、Atlas がソース レプリカセットに接続できることを確認します。

    検証に失敗した場合は、以下を確認します。

    • ソース レプリカセットの IP アクセス リストに Atlas を追加しました。

    • ユーザー認証情報(指定した場合)がソースクラスターに存在しており、必要な権限を持っている。

    • Is encryption in transit enabled? トグルは、ソースクラスターで必要な場合にのみ有効になっている。

    • CA ファイル(指定した場合)は有効かつ正しい。

  6. Start Migration をクリックして、移行プロセスを開始します。

    移行プロセスが開始されると、Atlas UI に、宛先 Atlas クラスターの Migrating Data ウォークスルー画面が表示されます。

    ウォークスルー画面は、宛先クラスターの移行プロセスが進行すると更新されます。移行プロセスには、次のものが含まれます。

    • ソースクラスターから宛先クラスターへのコレクションのコピー。

    • 宛先クラスターでのインデックスの作成。

    • ソースクラスタからの oplog エントリの追尾。

    最後の oplog を追尾するフェーズでは、ソースクラスターと宛先クラスター間の現在のラグを表すラグ タイム値が表示されます。このラグ タイムは、ソースクラスターでの oplog 生成速度によって変動する可能性がありますが、ライブ移行プロセスで oplog エントリが宛先クラスターにコピーされるにつれ、時間の経過とともに減少するはずです。

    ラグ タイマーとPrepare to Cutover ボタンが緑色に変わったら、次の手順に進みます。

2

Atlas は、ソースクラスターと宛先クラスターがほぼ同期していることを検出すると、延長可能な 120 時間(5 日)のタイマーを開始してライブ移行手順のカットオーバーのステージを開始します。120 時間が経過すると、Atlas はソースクラスターとの同期を停止します。<time> left to cut over タイマーの下の Extend time をクリックすると、残り時間を 24 時間延長できます。

移行の有効期限が迫っている場合、Atlas は次の例のようなメールを送信します。

A migration to your Atlas cluster will expire in <number> hours!
Navigate to your destination cluster to start the cutover process. If
you don't take any action within <number> hours, the migration will be
cancelled and you will need to start again. You can also extend the
migration process if you need more time.
  1. アプリケーションを宛先の Atlas クラスターに移行する準備ができたら、Prepare to Cutover をクリックします。

  2. Atlas には一連のページが表示され、カットオーバー プロセスの各ステージについてガイドします。 次のリストの一部の項目では、実行する必要があるアクションについて説明しています。他の項目では、Atlas が表示する情報メッセージについて説明しています。

    1. アプリケーションを停止します。これにより、ソースクラスターでこれ以上の書込み (write) が発生しなくなります。

    2. Atlas に次のメッセージが表示される画面が表示されます: Almost done! Waiting for Atlas to clean up ... 。 Atlas が移行を確定します。 これには数時間かかる場合があります。 移行を確定する間に、Atlas はメタデータの変更を完了し、宛先クラスターの IP アクセス リストから MongoDB Application Server のサブネットを削除し、ライブ移行が宛先クラスターへのデータのインポートに使用したデータベースユーザーを削除します。

      カットオーバー プロセスが少なくとも12時間進行している場合、Atlas は移行プロセスを確認するか、サポートに連絡することを提案するメールを送信します。

      Atlas はまだ移行を終了していますが、宛先クラスターは書き込みを受け入れる準備ができています。 ダウンタイムを最小限に抑えるには、アプリケーションを再起動し、新しい Atlas 宛先クラスターに接続できるようになりました。 移行が完全に完了するまで、ソースクラスターを削除しないでください。

      • [ Connect to your new clusterをクリックします。 Atlas は接続方法を選択できるConnect to Atlasページにリダイレクトします。

      • 宛先クラスターへの書込みを再開します。

      • アプリケーションが宛先の Atlas クラスターで動作していることを確認し、宛先クラスターでデータを検証します。

    3. 移行が成功すると、 You have successfully migrated to Atlasページが表示されます。

ライブ移行プロセスのいずれかの段階で移行が失敗した場合、Atlas は移行結果を確認するためのリンクを記載したメールで通知を行います。

このドキュメントで説明されている範囲外で移行のサポートに関して質問がある場合、または移行中にエラーが発生した場合は、Atlas UI からサポートをリクエストしてください。

サポートチケットを提出するには:

1
  1. まだ表示されていない場合は、希望するプロジェクトを含む組織を選択しますナビゲーション バーのOrganizationsメニュー

  2. まだ表示されていない場合は、ナビゲーション バーのProjectsメニューから目的のプロジェクトを選択します。

  3. Projects メニューの横にある Options メニューをクリックし、 Project Support をクリックします。

    プロジェクト サポートページが表示されます。

2
  1. [Request Support] をクリックします。

  2. Issue Category の場合は Help with live migration を選択します。

  3. Priority には、お問い合わせの優先度を選択します。ご質問の場合は、Medium Priority を選択してください。移行に失敗した場合は、High Priority を選択してください。

  4. Request Summary には、Live Migration を要約に含めてください。

  5. More details には、ご質問または移行エラーに関するその他の詳細も含めてください。

  6. Request Support ボタンをクリックして、フォームを送信します。

戻る

Atlas に引き込む