シャーディングされたクラスターの Atlas へのライブ移行(プル)(MongoDB 6.0.13以前)

移行パス

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

ネットワーク アクセス

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

移行前の検証

Atlas は、ライブ移行手順を開始する前に、ソースクラスターと宛先クラスターに対してさまざまな検証チェックを実行します。

• ソースクラスターはシャーディングされたクラスターである必要があります。

  ソースがレプリカセット クラスターの場合は、プル タイプのライブ移行を使用して、まず Atlas レプリカセットにクラスターを移行してから、クラスターをシャーディングされたクラスターにスケーリングします。

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

• ソースクラスターは CSRS（Config Server Replica Sets）を使用する必要があります。 「レプリカセット構成サーバー 」を参照してください。

• Atlas は、ソースクラスター内の各ノードのホスト名とポートに接続している必要があります。

• Atlas は、ソースクラスター上のシャーディングされたクラスター バランサーを停止して起動できる必要があります。

• ソースクラスターは、宛先クラスターと同じ機能の互換性バージョンとメジャー MongoDB バージョンを持っています。 フル5.0.xのメジャー MongoDB バージョン バージョンは5.0です。

  ソースクラスター内のホストの機能の互換性バージョンを確認するには、 mongoshから次のコマンドを実行します。

  db.runCommand( { getParameter : 1, "featureCompatibilityVersion" : 1 } )

  必要に応じてsetFeatureCompatibilityVersionデータベースコマンドを使用して、 featureCompatibilityVersionフラグを設定します。

• 宛先 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 認証を有効にせずにプル型のライブ移行を使用して移行できます。

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が使用されます。 Atlas でデータベースユーザーを作成する方法については、「データベースユーザーの構成 」を参照してください。

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

ソースクラスター バランサー

Atlas ライブ移行では、手順の開始時にソースクラスター上のシャーディングされたクラスターのバランサーが停止し、手順の最後にバランサーが起動されます。

ライブ移行をキャンセルすると、Atlas はソースクラスターのバランサーを再起動します。

宛先クラスターの構成

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

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

  ヨーロッパ

  • フランクフルト

  • アイルランド

  • London

  Americas

  • アメリカ東部

  • アメリカ西部

  APAC

  • ムンバイ

  • 香港

  • シドニー

  • Tokyo

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

• oplog コレクションの無制限の増加を防ぐには、ライブ移行プロセスの実行中に固定の oplog サイズを設定します。 詳細については、「必要なアクセス権」と「 Atlas 構成オプション 」を参照してください。

• グローバルクラスターをライブ移行の宛先ターゲットにすることはできません。

  重要

  ライブ移行プロセスを開始すると、宛先 Atlas クラスターは変更できません。 宛先クラスターをスケールアップするには、ライブ移行プロセスをキャンセルしてから、クラスターをスケールアップして、ライブ移行プロセスを再開します。

宛先クラスターのネットワークアクセス

ライブ移行中は、宛先クラスター上のmongosプロセスがシャットダウンし、 mongosサーバーを介したクラスター接続が一時停止されます。 移行が完了すると、 mongosプロセスは自動的に再起動します。

宛先クラスターでワークロードを避ける

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

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

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

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

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

名前空間の変更を避ける

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

選挙を避ける

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

ローリング再起動

移行プロセスが完了すると、クラスターは一度に各ノードを 1 つずつ再起動します。 これは ローリング再起動 と呼ばれ、その結果、プライマリでフェイルオーバーが発生します。 スムーズな移行を行うには、宛先クラスターにデータを移行する前に、プライマリ フェイルオーバーのテスト手順の実行を検討してください。

ライブ移行のキャンセル

このプロセスは Cancelをクリックすることで、いつでもプロセスをキャンセルできます。 Atlas は、宛先クラスターが通常のアクセスの準備が整うまで、宛先クラスターのSharded Cluster Live Import in Progressメッセージを表示します。

ライブ移行プロセスが完了する前にキャンセルすると、Atlas はその時点までに移行されたデータを削除しません。 宛先クラスターと同じ Atlas クラスターを使用してライブ移行プロセスを再開すると、Atlas はクラスターからすべてのデータを消去します。

宛先クラスターのテスト

宛先クラスターにデータを移行してから、移行プロセスを停止して宛先クラスターをテストすると同時に、ソースクラスターを実行中の状態でアプリケーションにデータを提供することを検討してください。

宛先クラスターを本番データでテストするには、 テストステップまで移行手順に従います。 完全な移行プロセスを実行する準備ができたら、テスト ステップをスキップし、カットオーバーのステップに進みます。

移行前チェックリスト

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

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

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

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

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

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

手順