Migrar con mongomirror

Implementación MongoDB de origen

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

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

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

• 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.

• mongomirror no es compatible con índices TTL. Descarta cualquier índice TTL existente y vuelve a crearlos una vez terminado el proceso de migración. Si no deseas descartar un índice existente porque es importante para el rendimiento de la query, contacto con el soporte para explorar 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 utilizar el renameCollection comando ni la $out etapa de agregación como parte de la sincronización inicial, que se ejecuta como parte del mongomirror proceso.

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

• Si su implementación de MongoDB contiene índices con claves que exceden el límite de clave de índice, antes de comenzar el procedimiento de migración en vivo, modifique los índices para que no contengan claves de gran tamaño.

Acceso requerido en el set de réplicas de origen

mongomirror debe tener acceso de red al set de réplicas de origen. Si el set de réplicas de origen requiere autenticación, incluya las credenciales de usuario al ejecutar mongomirror. Especificar 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 los clústeres de origen que ejecutan MongoDB,3.4 un usuario debe tener, como mínimo,clusterMonitor los roles y. Por readAnyDatabase 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 del 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 versión que sea igual o posterior a la versión de MongoDB del clúster de origen. Consulta Ruta de actualización.

• No debe contener ningún namespace que se superponga con el clúster de origen. Si mongomirror detecta espacios de nombres superpuestos en el clúster de destino, falla antes de iniciar el proceso. Si el clúster de destino contiene espacios de nombres superpuestos, elimina todos los datos del clúster de destino con --drop, o enumera los espacios de nombres para importar desde el 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 ejecuta mongomirror, 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 del clúster, use la nslookup herramienta desde la línea de comandos. Para obtener más información, consulte ¿Cambian alguna vez las direcciones IP públicas del clúster Atlas?

Acceso requerido en el clúster de destino

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

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