以下を用いた移行: mongomirror

ソース MongoDB の配置

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

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

• ソースMongoDBレプリカセットは、無料クラスター（以前は M0）または Flex クラスターにすることはできません。

• ソースMongoDBレプリカセットには、時系列コレクション内のデータを含めることはできません。

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

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

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

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

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

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

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

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

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

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

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

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

そのようなユーザーが存在しない場合は、ソースMongoDBレプリカセットにユーザーを作成します。 MongoDB Server のバージョンによって、組み込みロールが異なります。自分の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 の配置:

• 無料クラスターまたは Flex クラスターにすることはできません。

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

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

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

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

  • が実行中いるサーバーのパブリックIPアドレス、または

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

  注意

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

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

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

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