以下を用いた移行: mongomirror

ソース MongoDB の配置

• ソース MongoDB の配置はレプリカセットである必要があります。ソースがスタンドアロンの MongoDBデプロイである場合は、 mongomirror実行中、 を実行してスタンドアロンをレプリカセットに変換します。

• ソース レプリカセットでは MongoDB バージョン 2.6 以降を実行する必要があります。

• ソースMongoDBレプリカセットは、 M0無料クラスターまたはM2/M5共有クラスターにはできません。

• 手順中はいつでも featureCompatibilityVersion フラグを変更しないでください。

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

• mongomirror は TTL インデックスと互換性がありません。既存の TTL インデックスをすべて削除し、移行プロセスが完了した後に再度ビルドします。既存のインデックスがクエリ パフォーマンスにとって重要で、削除を避けたい場合は、別の方法についてサポートにお問い合わせください。

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

• 最初の同期は mongomirror プロセスの一部として実行され、renameCollection コマンドや $out 集約ステージは使用できません。

• 最初の同期の段階でプライマリを再起動しないでください。

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

ソース レプリカ セットで必要なアクセス

mongomirror には、ソース レプリカ セットへのネットワーク アクセス権が必要です。ソース レプリカ セットに認証が必要な場合は、mongomirror を実行するときにユーザー認証情報を含める必要があります。少なくとも次の権限を持つデータベース ユーザーを指定する必要があります。

• すべてのデータベースとコレクションを読み取ります。admin データベースの readAnyDatabase ロールがこの要件をカバーします。

• oplog を読みとります。「Oplog アクセス権限」を参照してください。

• getParameter コマンドを実行します。

そのようなユーザーが存在しない場合は、ソース MongoDB レプリカセットにユーザーを作成します。MongoDB サーバーのバージョンによって、組み込みロールが異なります。自分の MongoDB Server バージョンに基づいて組み込みロールを選択し、mongosh　で適切なコマンドを実行します。

• ソースクラスターの場合、ユーザーには 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 の配置:

• M0無料クラスター、 M2 、またはM5共有クラスターにすることはできません。

• サーバーレスインスタンスにすることはできません。

• レプリカセットでなくてはなりません。

• ソースクラスターの MongoDB のバージョンと同じかそれ以降のバージョンが必要です。アップグレード パスを参照してください。

• ソース クラスターと重複する名前空間を含めることはできません。mongomirror が宛先クラスター上で重複する名前空間を検出すると、プロセスを開始する前に失敗します。宛先クラスターに重複する名前空間が含まれている場合は、--drop を使用して宛先クラスターからすべてのデータを削除するか、--includeNamespace を使用してソースクラスターからインポートする名前空間を一覧表示します。

• そのIP アクセス リストには、以下のいずれかを含めなければなりません。

  • mongomirrorが稼働しているサーバーのパブリック IP アドレス、または

  • VPC ピアリング用に設定されている場合は、ピアリングの VPC CIDR ブロック（またはそのサブセット）、あるいはピア VPC のセキュリティ グループのいずれか。

  注意

  クラスター内の任意のノードのパブリック IP アドレスを確認するには、コマンドラインから nslookup ツールを使用します。詳しくは、「Atlas クラスターのパブリック IP の変更」を参照してください。

宛先クラスターで必要なアクセス

mongomirror には、宛先クラスターへのネットワーク アクセス権が必要です。

mongomirror を実行するには、Atlas admin ロールを持つデータベースユーザーを指定する必要があります。詳細については、「データベース ユーザーの追加」を参照してください。