レプリカセットの Atlas へのライブ移行（プル）（ MongoDB 6.0.13以前）

移行パス

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

ネットワーク アクセス

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

移行前の検証

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

• ソースクラスターはレプリカセットである。

  ソースクラスターがスタンドアロンの場合は、プル タイプのライブ移行を使用する前に、まずスタンドアロンをレプリカセットに変換します。

• 宛先のAtlas クラスターはレプリカセットです。

ソースクラスタのセキュリティ

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

• ソースクラスターの場合、ユーザーには readAnyDatabase、clusterMonitor、および 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 アクセス」を参照してください。

• MongoDB 3.4 を実行しているソースクラスターの場合、ユーザーには少なくとも clusterMonitor と readAnyDatabase の両方のロールが必要です。以下に例を挙げます。

   use admin
   db.createUser(
     {
       user: "mySourceUser",
       pwd: "mySourceP@$$word",
       roles: [ "clusterMonitor", "readAnyDatabase" ]
     }
   )

• MongoDB 3.2 を実行しているソースクラスターの場合、ユーザーには少なくとも clusterManager と readAnyDatabase の両方のロールと、local データベースに対する読み取りアクセス権が必要です。これには、以下のコマンドで作成できるカスタムロールが必要です。

    use admin
    db.createRole(
         {
           role: "migrate",
           privileges: [
             { resource: { db: "local", collection: "" }, actions: [ "find" ] }
           ],
           roles: ["readAnyDatabase", "clusterManager"]
         }
       )
     db.createUser(
         {
           user: "mySourceUser",
           pwd: "mySourceP@$$word",
           roles: [ "migrate" ]
         }
       )

• MongoDB 2.6 または 3.0 を実行しているソースクラスターの場合、ユーザーには少なくとも readAnyDatabase ロールが必要です。以下に例を挙げます。

    use admin
       db.createUser(
         {
           user: "mySourceUser",
           pwd: "mySourceP@$$word",
           roles: [ "readAnyDatabase" ]
         }
       )

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

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

SCRAM 認証のサポートは MongoDB 3.0 から開始されました。ソースクラスターが MongoDB 2.6 を実行している場合は、SCRAM 認証を有効にせずにプル型のライブ移行を使用して移行できます。

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

MongoDB のライブ移行サーバーの保護方法

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 が使用されます。詳細については、「データベースユーザーの設定」を参照してください。

SCRAM 認証のサポートは MongoDB 3.0 から開始されました。ソースクラスターが MongoDB 2.6 を実行している場合は、SCRAM 認証を有効にせずにプル型のライブ移行を使用して移行できます。

宛先クラスターの構成

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

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

  ヨーロッパ

  • フランクフルト

  • アイルランド

  • London

  Americas

  • アメリカ東部

  • アメリカ西部

  APAC

  • ムンバイ

  • 香港

  • シドニー

  • Tokyo

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

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

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

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

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

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

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

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

  • クラスターの増加

  • Atlas 構成オプション

  • Cluster-to-Cluster Sync ドキュメントの oplog サイズ設定 。

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

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

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

• このページに記載されている手順で、お使いのクラスターを MongoDB v6.0 以降に移行することはできません。

  ソースクラスターと宛先クラスターが MongoDB 6.0.13以降を実行している場合は、この手順を使用して Atlas へのライブ移行ができます。

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

ターゲット クラスターでワークロードを避ける

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

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

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

クラウドバックアップを避ける

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

名前空間の変更を避ける

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

選挙を避ける

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

移行前チェックリスト

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

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

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

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

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

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

手順

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.