Migrar con mongomirror

Implementación de MongoDB de origen

• La implementación de MongoDB de origen debe ser un conjunto de réplicas. Si la implementación de MongoDB de origen es independiente, antes de mongomirror ejecutar, conviértala en un conjunto 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 M0 ni un clúster Flex.

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

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

• Cuando migra desde MongoDB 4.4 o una versión anterior a un clúster Atlas que ejecuta MongoDB o una versión 7.0 posterior, elimine todos los índices geoHaystack de sus 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 servidor principal 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 al conjunto de réplicas de origen

mongomirror debe tener acceso de red al conjunto de réplicas de origen. Si el conjunto de réplicas de origen requiere autenticación, incluya las credenciales de usuario al ejecutar. Especifique un usuario de base de datos con, como mínimo, los siguientes mongomirror privilegios:

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

• Lea el registro de operaciones. Consulte Acceso al registro de operaciones.

• Ejecute el getParameter comando.

Si no existe dicho usuario, créelo en el conjunto de réplicas de MongoDB de origen. Cada versión de MongoDB Server tiene diferentes roles integrados. Seleccione un rol integrado según su versión de MongoDB Server y ejecute los comandos correspondientes mongosh en:

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

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

  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, los roles y, así como acceso de lectura a clusterManager readAnyDatabase la local base de datos. Esto requiere un rol personalizado, que puede crearse 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. Por readAnyDatabase 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 gratuito M0 ni un clúster flexible.

• Debe ser un conjunto de réplicas.

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

• No debe contener espacios de nombres que se superpongan 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, elimine todos los datos del clúster --drop de destino con o enumere los espacios de nombres que se importarán del clúster de origen --includeNamespace con.

• Debe incluir en su lista de acceso IP:

  • La dirección IP pública del servidor en el que se ejecuta,mongomirror o

  • Si se configura para el emparejamiento de VPC, el bloque CIDR de VPC del par (o un subconjunto) o el grupo de seguridad de la VPC del 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.

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