Descripción
Revierte la dirección de una operación de sincronización confirmada.
Por ejemplo:
Tienes una operación de sincronización
COMMITTED.cluster0es la fuente ycluster1es el destino.Después de que la operación de sincronización esté
COMMITTED, las nuevas escrituras solo ocurren en el clúster de destino. El clúster de origen no aceptará nuevos guardados.
En este escenario, puedes utilizar el endpoint reverse para sincronizar los guardados de cluster1 a cluster0, incluidos los guardados que ocurrieron en cluster1 después de que mongosync alcanzó canWrite=true. Para comprobar el estado de canWrite durante la sincronización, usa el comando /progress endpoint.
Para obtener más información y un tutorial sobre cómo utilizar el endpoint reverse, consulta Sentido inverso de sincronizar.
Requisitos
Para usar el reverse endpoint:
mongosyncdebe estar configurado cuando comience la sincronización inicial. La llamada al endpoint de API /start debe establecer:reversibletotrueenableUserWriteBlockinga"sourceAndDestination".
Nota
El doble bloqueo de escritura es un requisito previo para ejecutar reverse.
No puede actualizar estas opciones después de que se inicie la sincronización.
mongosyncdebe estar en el estadoCOMMITTED.El oplog del clúster de destino no debe reiniciarse entre que
mongosyncalcancecanWrite=truey reciba la solicitud/reverse.
Advertencia
Índices únicos en el clúster de origen no deben usar el formato heredado.
Para validar que los índices de la colección en el clúster de origen usen el formato adecuado, consulta Validar índices únicos.
Los clústeres de origen y destino deben tener el mismo número de particiones. No se puede sincronizar de forma inversa cuando los clústeres tienen diferentes topologías.
Los clústeres de origen y destino deben ejecutar la misma versión principal de MongoDB.
El usuario especificado en la cadena de conexión
mongosyncdebe tener los permisos requeridos en los clústeres de origen y destino. Los permisos varían dependiendo del entorno y si deseas modificar la configuración de bloqueo de escritura o utilizar la sincronización inversa.
Nota
Cuando configures múltiples instancias de mongosync para sincronizarse entre clústeres fragmentados, debes enviar comandos idénticos de puntos finales API a cada instancia de mongosync.
Para obtener más información, consulta Revertir varios Mongosyncs.
Validate Unique Indexes
Para invertir la dirección, mongosync requiere que todos los índices únicos en el clúster de origen (excepto _id) no tengan claves de índice único heredadas.
Antes de comenzar
Puedes asegurarte de que los índices únicos que no son de_id utilicen el formato correcto en el clúster de origen con la etapa de agregación $collStats. Para ejecutar esta pipeline de agregación en tu colección, copia y pega el código de ejemplo, reemplazando <collection> con el nombre de la colección y <field_name> con el nombre del campo indexado. Debe ejecutar esto en todos los nodos, para todas las colecciones que tengan índices únicos. Tenga en cuenta que solo los índices únicos no-_id deben tener formatVersion 13 o 14.
db.<collection>.aggregate( [ { $collStats: { storageStats: { } } }, { $project: { "storageStats.indexDetails.<index_name>.metadata.formatVersion": 1 } } ] )
[ { storageStats: { indexDetails: { <field_name>: { metadata: { formatVersion: 14 } } } } } ]
Se garantiza que los índices únicos con formatVersion 13 o 14 no tienen claves heredadas.
Si tienes índices únicos de una versión de formato diferente, también puedes usar el método db.collection.validate() con full = false para confirmar si existen claves de índices legacy. Debe ejecutar esto en todos los nodos para todas las colecciones con índices únicos. validate() devuelve una advertencia si se detectan claves de índice en formato heredado.
Pasos
Para actualizar la versión de formato de los índices para la compatibilidad con mongosync, se debe resincronizar todos los nodos del clúster de origen original. Para volver a sincronizar todos los nodos:
Resincronizar todos los secundarios, uno por uno.
Para un tutorial sobre cómo resincronizar nodos, consulta Resincronizar un nodo de un set de réplicas.
Solicitud
POST /api/v1/reverse
Parámetros del cuerpo de la solicitud
Este endpoint no utiliza parámetros del cuerpo de la solicitud HTTP. Sin embargo, debes especificar la opción --data con un objeto vacío { }.
Respuesta
Campo | Tipo | Descripción |
|---|---|---|
| booleano | Cuando la solicitud es exitosa, este valor es |
| string | Si se produce un error, se indicará el nombre del error. Este campo se omite de la respuesta cuando |
| string | Descripción detallada del error que ocurrió. Este campo se omite en la respuesta cuando |
Ejemplo
El siguiente ejemplo invierte la dirección de una operación de sincronización confirmada.
Solicitud
curl localhost:27182/api/v1/reverse -XPOST --data '{ }'
Respuesta
{"success":true}
Comportamiento
El terminal reverse inicia el estado REVERSING. mongosync intercambia los clústeres de origen y destino y reanuda la aplicación de eventos de cambio.
Si la sincronización con reverse es exitosa, mongosync entra en el estado de RUNNING. La sincronización continúa en sentido inverso a la tarea de sincronización original. No es necesario reiniciar todo el proceso de sincronización para copiar los datos originales.
Para ver la dirección de mapeo para la sincronización de los clústeres de origen y destino, utiliza el endpoint progreso y verifica el objeto directionMapping.
Verificador Integrado
El verificador integrado está habilitado por defecto para migraciones de sets de réplicas.
Protección de endpoints
mongosync no protege el punto de conexión reverse. Sin embargo, por defecto, la API se vincula únicamente a localhost y no acepta llamadas de otras fuentes. Además, la llamada reverse no expone credenciales de conexión ni datos de usuario.
Limitaciones
El endpoint reverse no admite lo siguiente:
Migraciones desde clústeres de origen anteriores a6.0.