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

• 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 puedes usar el comando renameCollection ni la fase de agregación $out como parte de la sincronización inicial, que se ejecuta como parte del proceso mongomirror.

• 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

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

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.