Migrar con mongomirror

Implementación MongoDB de origen

• La implementación de MongoDB de origen debe ser un set de réplicas. Si la fuente es una implementación independiente de MongoDB, antes de ejecutar , convierta la instancia independiente en un set de réplicas.

• El set de réplicas de origen debe ejecutar MongoDB versión 2.6 o superior.

• El set de réplicas de origen de MongoDB no puede ser un clúster gratuito (anteriormente conocido como M0) ni un clúster Flex.

• El set de réplicas de origen de MongoDB no puede contener datos en colecciones de series de tiempo.

• No cambie la bandera featureCompatibilityVersion en ningún momento durante el procedimiento.

• Cuando migres de MongoDB 4.4 o versiones anteriores a un clúster de Atlas que ejecute MongoDB 7.0 o posterior, descarta cualquier índice geoHaystack de tus colecciones.

• no es compatible con índices TTL. Descarta cualquier índice TTL existente y reconstruyelos cuando el proceso de migración esté completo. Si no desea descartar un índice existente porque es importante para el rendimiento de las query, comuníquese con soporte para opciones alternativas.

• No hagas ningún cambio de namespace durante el proceso de migración, como usar el comando renameCollection o ejecutar un pipeline de agregación que incluya la etapa de agregación $out.

• No puede usar el comando renameCollection o la etapa de agregación $out como parte de la sincronización inicial, que se ejecuta como parte del proceso.

• No reinicie el primario durante la etapa de sincronización inicial de la migración.

• Si la implementación de MongoDB contiene índices con claves que superan el Límite de Claves de Índice, antes de iniciar el procedimiento de migración en vivo, se deben modificar los índices para que no contengan claves sobredimensionadas.

Acceso requerido en el set de réplicas de origen

debe tener acceso a la red al set de réplicas fuente. Si el set de réplicas requiere autenticación, incluye las credenciales del usuario al ejecutar. Especifique un usuario de base de datos con, como mínimo, los siguientes privilegios:

• Leer todas las bases de datos y colecciones. El readAnyDatabase rol en la base de datos admin cubre este requisito.

• Lea el oplog. Consulta Acceso a Oplog.

• Ejecute el comando getParameter.

Si no existe tal usuario, crea el usuario en el set de réplicas MongoDB de origen. Diferentes versiones del MongoDB Server tienen diferentes roles incorporados. Seleccione un rol integrado según su versión de MongoDB Server y ejecute los comandos apropiados en la mongosh:

• Para clústeres de origen, un usuario debe tener los roles readAnyDatabase, clusterMonitor y backup.

  Para verificar que el usuario de la base de datos que ejecutará el proceso de Migración en vivo tiene estos roles, ejecuta el comando db.getUser() en la base de datos admin.

  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"
      }
    ]
  } ...

  Además, el usuario de base de datos de su clúster de origen debe tener el rol para leer el oplog en la base de datos admin. Para obtener más información, consulta Acceso al Oplog.

• Para clústeres de origen que ejecutan MongoDB 3.4, un usuario debe tener, como mínimo, los roles clusterMonitor y readAnyDatabase . Por ejemplo:

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

• Para los clústeres de origen que ejecutan MongoDB 3.2 un usuario debe tener, como mínimo, tanto los roles de clusterManager como de readAnyDatabase, así como acceso de lectura a la base de datos local. Esto requiere un rol personalizado, que se puede crear con los siguientes comandos:

    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" ]
         }
       )

• Para los clústeres de origen que ejecutan MongoDB 2.6 o 3.0, un usuario debe tener, como mínimo, el rol readAnyDatabase. Por ejemplo:

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

Implementación de Atlas de destino

La implementación de destino de Atlas:

• No puede ser un clúster Gratis ni un clúster Flex.

• Debe ser un set de réplicas.

• Debe tener la misma versión o una posterior a la versión de MongoDB del clúster de origen. Consulte la ruta de actualización.

• No debe contener ningún namespace que se superponga con el clúster de origen. Si detecta superposición de espacios de nombres en el clúster de destino, el proceso falla antes de comenzar. Si su clúster de destino contiene namespaces superpuestos, borrar todos los datos del clúster de destino con --drop, o lista los namespaces que desea importar del clúster de origen con --includeNamespace.

• Debe incluir en su lista de acceso IP, ya sea:

  • La dirección IP pública del servidor en el que se está ejecutando, o

  • Si se configura para el emparejamiento de VPC, ya sea el bloque CIDR de VPC del par (o un subconjunto) o el grupo de seguridad del VPC par.

  Nota

  Para encontrar la dirección IP pública de cualquier nodo de tu clúster, utiliza la herramienta nslookup de la línea de comandos. Para obtener más información, consulta ¿Cambian alguna vez las IP públicas del clúster de Atlas?

Acceso requerido en el clúster de destino

debe tener acceso a la red del clúster de destino.

Debes especificar un usuario de base de datos con el Atlas admin rol para ejecutar. Para obtener más información, consulta Configurar usuarios de bases de datos.