start

Estado

Para utilizar el endpoint start, mongosync debe estar en el estado IDLE.

Permisos

El usuario especificado en la cadena de conexión mongosync debe tener los permisos requeridos en los clústeres de origen y destino. Consultar Permisos de usuario para asegurar que el usuario tenga los permisos correctos para iniciar la sincronización.

Instancias múltiples de mongosync

Asegura que uses el usuario mongosync configurado en las cadenas de conexión para la configuración de cluster0 o cluster1 cuando inicies mongosync.

Parámetros del cuerpo de la solicitud

db.adminCommand( { setUserWriteBlockMode: 1, global: false } )

Parámetros de partición

Para sincronizar desde un set de réplicas a un clúster, configura la opción sharding para particionar las colecciones en el clúster de destino.

mongosync lanza un error si la opción sharding no está configurada cuando se sincroniza desde un set de réplicas a un clúster fragmentado. mongosync también lanza un error si la opción sharding se configura con cualquier otra configuración.

La opción sharding tiene los siguientes parámetros:

Iniciar una tarea de sincronización

El siguiente ejemplo inicia un trabajo de sincronización entre el clúster de origen cluster0 y el clúster de destino cluster1.

solicitud:

curl localhost:27182/api/v1/start -XPOST \
--data '
   {
      "source": "cluster0",
      "destination": "cluster1"
   } '

Respuesta:

{"success":true}

Inicia una tarea de sincronización reversible

El siguiente ejemplo inicia un trabajo de sincronización entre el clúster de origen cluster0 y el clúster de destino cluster1.

Los campos reversible y enableUserWriteBlocking permiten que la sincronización sea reversible. Para invertir la dirección de la sincronización, consulta: inverso.

solicitud:

curl localhost:27182/api/v1/start -XPOST \
--data '
   {
      "source": "cluster0",
      "destination": "cluster1",
      "reversible": true,
      "enableUserWriteBlocking": "sourceAndDestination"
   } '

Respuesta:

{"success":true}

Iniciar una tarea de sincronización filtrada

El siguiente ejemplo inicia un trabajo de sincronización entre el clúster de origen cluster0 y el clúster de destino cluster1.

cluster0 contiene las bases de datos sales, marketing y engineering.

La base de datos sales contiene las colecciones EMEA, APAC y AMER.

El arreglo includeNamespaces en este ejemplo define un filtro en dos de las bases de datos, sales y marketing.

La base de datos sales también filtra en las colecciones EMEA y APAC.

"includeNamespaces" : [
      {
          "database" : "sales",
          "collections": [ "EMEA", "APAC" ]
      },
      {
          "database" : "marketing"
      }
   ]

Después de que llames a la API /start con este filtro activado, mongosync:

• Sincroniza todas las colecciones en la base de datos marketing

• Filtra la base de datos engineering

• Sincroniza las colecciones EMEA y APAC de la base de datos sales

• Se filtra la colección AMER

La opción includeNamespaces crea un filtro. Para filtrar la sincronización, consulta: Sincronización filtrada

solicitud:

curl -X POST "http://localhost:27182/api/v1/start" --data '
   {
      "source": "cluster0",
      "destination": "cluster1",
      "includeNamespaces": [
         {
             "database": "sales",
             "collectionsRegex": {
                "pattern": "^accounts_.+$",
                "options": "i"
             }
         }, {
            "database": "marketing"
         }
      ]
   } '

Respuesta:

{"success":true}

Iniciar sincronizar desde set de réplicas a clúster

El siguiente ejemplo inicia una tarea de sincronización entre el set de réplicas de origen cluster0 y el clúster fragmentado de destino cluster1. El arreglo key en este ejemplo define la clave de partición {"location": 1, "region": 1 }.

solicitud:

curl localhost:27182/api/v1/start -XPOST \
--data '
   {
      "source": "cluster0",
      "destination": "cluster1",
      "sharding": {
         "createSupportingIndexes": true,
         "shardingEntries": [
            {
                "database": "accounts",
                "collection": "us_east",
                "shardCollection": {
                   "key": [
                      { "location": 1 },
                      { "region": 1 }
                   ]
                }
            }
         ]
      }
   } '

Respuesta:

{"success":true}

Inicia con el Verificador deshabilitado

A partir de 1.9, el verificador incrustado se ejecuta por defecto cuando se inicia una migración. Si necesitas deshabilitarlo, configura verification.enabled a false.

solicitud:

curl localhost:27182/api/v1/start -XPOST \
--data '
   {
      "source": "cluster0",
      "destination": "cluster1",
      "verification": {
         "enabled": false
      }
   } '

Respuesta:

{"success":true}

Debes verificar que una migración fuera exitosa antes de transferir la carga de tu aplicación al clúster de destino. Si necesita desactivar el verificador por cualquier motivo, utilice un método alternativo para verificar la sincronización.

Verificador Integrado

A partir de 1.9, mongosync proporciona un verificador integrado para determinar si la transferencia de datos del clúster de origen al de destino fue exitosa.

Cuando se activa, el verificador realiza una serie de comprobaciones de verificación en el clúster de destino. Si alguna de estas comprobaciones devuelve un error, el verificador falla la migración. Si todas las comprobaciones se realizan correctamente, mongosync pasa al estado COMMITTED.

Para desactivar el verificador, consulta Comenzar con el verificador desactivado.

El punto de enlace /start devuelve un error si se habilitan controles de verificación que no son compatibles con el clúster de origen o destino, o si no hay suficiente memoria.

Estado

Si la solicitud start es exitosa, mongosync entra en el estado RUNNING.

Partición Set de Réplicas

Sincronizar desde un set de réplicas a un clúster requiere la opción sharding. Esta opción configura cómo mongosync las colecciones de fragmentos.

El arreglo sharding.shardingEntries especifica las colecciones a particionar. Las colecciones que no se listan en este arreglo se replican como no fragmentadas.

Para obtener más información, consulta Comportamiento de clúster particionado.

Índices de soporte

mongosync sincroniza los índices del clúster de origen al clúster de destino. Cuando se sincroniza desde un set de réplicas a un clúster particionado, mongosync puede requerir un índice adicional para admitir la clave de partición, que puede no existir en el clúster de origen.

mongosync puedes crear índices auxiliares para colecciones particionadas durante la sincronización. Esto se realiza estableciendo la opción sharding.createSupportingIndexes.

Cuando sharding.createSupportingIndexes es false (el valor por defecto):

• Cada clave de partición proporcionada para la opción sharding.shardingEntries debe tener un índice existente en el clúster de origen.

• Uno de los índices utilizados para la clave de partición debe tener una intercalación simple si la colección utiliza cualquier otra intercalación.

• Para usar un índice único en la clave de partición, debes especificar su unicidad cuando crees el índice en el clúster de origen.

• Los índices únicos en el clúster de origen que son incompatibles con la clave de partición solicitada en el clúster de destino, como un índice único en el origen que no contiene la clave de partición solicitada como prefijo en el clúster de destino, pueden causar que mongosync falle.

Cuando sharding.createSupportingIndexes es true:

• Si los índices de soporte existen en el clúster de origen, mongosync sincroniza los índices con el clúster de destino y los utiliza como claves de partición.

• Si los índices de soporte no existen, mongosync los crea en el clúster de destino.

La opción sharding.createSupportingIndexes afecta a todas las colecciones fragmentadas.

Renombrar Durante la Sincronización

Las colecciones listadas en el arreglo sharding.shardingEntries al sincronizarse de un set de réplicas a un clúster, se convierten en colecciones particionadas en el clúster de destino.

Renombrar una colección (como con el comando renameCollection) en el clúster de origen después de llamar a start pero antes de que mongosync comience a copiar la colección puede bloquear la partición de la colección en el destino.

Para comprobar si es seguro renombrar colecciones, llama al endpoint progress y revisa el valor del campo collectionCopy.estimatedCopiedBytes en el documento de retorno.

• Un valor de 0 indica que mongosync no ha comenzado a copiar la colección.

  Renombrar una colección en este punto puede resultar en una colección no particionada en el clúster de destino, ya que la transición a la copia puede ocurrir antes de que el cambio de nombre surta efecto en el origen.

• Un valor mayor que 0 indica que mongosync ha empezado a copiar. Renombrar la colección desde este punto en adelante no bloquea su particionado en el clúster de destino, incluso en el evento de un fallo.

Índices requeridos

Cuando se llama a /start con la opción buildIndexes configurada en never, mongosync omite crear índices innecesarios.

Los índices que siempre se compilan incluyen:

• mongosync construye un índice en el campo _id de cada colección que copia.

• mongosync construye índices ficticios para cada colección particionada que no tenga un índice para admitir la clave de partición en el clúster de destino. Cuando buildIndexes se establece en never, mongosync mantiene este índice después de la confirmación.

Protección de endpoints

mongosync no protege el punto de conexión start. Sin embargo, por defecto, la API se vincula únicamente a localhost y no acepta llamadas de otras fuentes. Además, la llamada start no expone credenciales de conexión ni datos de usuario.