Puedes finalizar una migración y transferir la carga de trabajo de tu aplicación desde el clúster de origen al de destino usando la Proceso de transición demongosync.
mongosync debe permanecer activo hasta alcanzar el estado COMMITED. Esto permite que mongosync sincronice cualquier guardados adicional que ocurra durante la migración.
Nota
Antes de trasladar la carga de trabajo de tu aplicación al clúster de destino, siempre debes verificar que la sincronización se haya realizado exitosa. Para obtener más información, consulta Verificar transferencia de datos.
Pasos
Verificar el estado de mongosync.
Llame al endpoint de progreso para determinar el estado de mongosync antes de iniciar el proceso de corte. Asegúrese de que el estado del proceso mongosync indique los siguientes valores:
canCommitestrue.lagTimeSecondses pequeño (cerca de0).Si
lagTimeSecondsno está cerca de0cuando comience el corte, este podría tardar mucho tiempo.Al usar el Verificador Integrado, verifique
verification.sourcelosverification.destinationdocumentos de retorno y. LoslagTimeSecondscampos en ambos documentos deben estar cerca0phase"stream hashing"de y los campos deben mostrar.Si el verificador no está en la fase de hash de flujo, el proceso de transición podría tomar mucho tiempo.
El siguiente ejemplo devuelve el estado del proceso de sincronización.
Solicitud
curl localhost:27182/api/v1/progress -XGET
Respuesta
{ "progress": { "state":"RUNNING", "canCommit":true, "canWrite":false, "info":"change event application", "lagTimeSeconds":0, "collectionCopy": { "estimatedTotalBytes":694, "estimatedCopiedBytes":694 }, "directionMapping": { "Source":"cluster0: localhost:27017", "Destination":"cluster1: localhost:27018" }, "source": { "pingLatencyMs":250 }, "destination": { "pingLatencyMs":-1 }, "verification": { "source": { "estimatedDocumentCount": 42, "hashedDocumentCount": 42, "lagTimeSeconds": 2, "totalCollectionCount": 42, "scannedCollectionCount": 10, "phase": "stream hashing" }, "destination": { "estimatedDocumentCount": 42, "hashedDocumentCount": 42, "lagTimeSeconds": 2, "totalCollectionCount": 42, "scannedCollectionCount": 10, "phase": "stream hashing" } } }, "success": true }
Detén cualquier operación de guardar en las colecciones sincronizadas en la fuente.
Espere a que todas las transacciones en el clúster de origen se confirmen o aborten.
mongosyncHabilita el bloqueo de escritura solo en el destino de forma predeterminada. Puede habilitarlo explícitamente iniciandomongosyncconenableUserWriteBlockingestablecido en"destinationOnly".mongosyncsolo bloquea las escrituras en el destino y las desbloquea justo antes de quecanWritese establezca entrue.Si inicia
mongosyncconenableUserWriteBlockingconfigurado en"sourceAndDestination",mongosyncbloquea todas las operaciones de guardar en el clúster de destino y las desbloquea justo antes de quecanWritese configure entrue.mongosyncbloquea los guardados en el origen después de que llames a/commit.Si inicia
mongosyncconenableUserWriteBlockingestablecido en"none", asegúrese de deshabilitar las escrituras. Por ejemplo, ejecute elsetUserWriteBlockModecomando en el clúster de origen:db.adminCommand( { setUserWriteBlockMode: 1, global: true } ) Si
mongosyncusa sincronización filtrada, no es necesario deshabilitar las escrituras en todo el clúster de origen. Sin embargo, debe asegurarse de detener las operaciones de escritura en las colecciones que incluye el filtro.
Envía una solicitud de commit a mongosync.
Si inicia varias instancias mongosync para su migración, debe emitir una solicitud de confirmación para cada instancia mongosync.
Solicitud
curl localhost:27182/api/v1/commit -XPOST --data '{ }'
Respuesta
{"success":true}
Nota
Después de enviar una solicitud commit, llame al punto final progress para asegurarse de que el estado mongosync sea COMMITTING o COMMITTED.
Si su clúster de origen contiene Configuraciones de Consultas Persistentes (PQS), debe migrar manualmente las PQS a su clúster de destino.
Si anteriormente configuraste enableUserWriteBlocking en sourceAndDestination, mongosync bloquea las escrituras en el clúster de origen una vez que completes este paso.
Si previamente configuró enableUserWriteBlocking en sourceAndDestination y mongosync falla durante este paso, debe desbloquear manualmente las escrituras en el clúster de origen setUserWriteBlockMode mediante.
Espere hasta que pueda realizar escrituras en el clúster de destino.
Llama al endpoint progress para determinar si canWrite está true. Si canWrite está false, espera hasta que progress muestre que canWrite está true. Si estás ejecutando múltiples instancias de mongosync, solo verifica que canWrite sea verdadero en el primer proceso mongosync. El estado canWrite de cualquier proceso mongosync posterior no es válido.
curl -sS localhost:27182/api/v1/progress -XGET | jq ".progress.canWrite"
true
Verificar transferencia de datos.
Verifica la sincronización exitosa de datos desde la fuente al clúster de destino.
Para obtener más información, consulta Verificar la transferencia de datos.
Si bloqueó manualmente las escrituras en el clúster de destino usando setUserWriteBlockMode, habilite las escrituras de la aplicación en el clúster de destino.
Para habilitar la escritura, actualiza setUserWriteBlockMode:
db.adminCommand( { setUserWriteBlockMode: 1, global: false } )
Luego, transfiera la carga de trabajo de su aplicación al clúster de destino.
Si inició mongosync con bloqueo de guardado utilizando la opción enableUserWriteBlocking en el endpoint /start, no necesita completar este paso.
Comportamiento
canWrite y COMMITTED
mongosync permite escrituras en el clúster de destino en una etapa anterior al estado COMMITTED.
Si configura enableUserWriteBlocking como "sourceAndDestination" o "destinationOnly", o si el verificador está activado, puede escribir en el destino después de que /progress informe canWrite: true. De lo contrario, espere hasta que el estado sea COMMITTED. Si ejecuta varias instancias de mongosync, use solo el estado canWrite del primer proceso mongosync.
En la sincronización inicial, mongosync replica los índices únicos en el clúster de origen como índices no únicos en el clúster de destino. Durante la confirmación, los índices no únicos relevantes en el clúster de destino se configuran a prepareUnique. Cuando esto se completa, el endpoint /progress comienza a devolver canWrite:
true. Las colecciones con prepareUnique índices rechazan nuevos documentos que violan la restricción de índice único. mongosync luego convierte los índices prepareUnique en índices únicos. Cuando esto se hace, mongosync cambia su estado a COMMITTED.
Nota
La conversión de índices prepareUnique a índices únicos puede ser intensiva en recursos al sincronizar grandes colecciones. Esto puede resultar en un largo tiempo entre el /progress endpoint que devuelve canWrite: true y mongosync que llega al COMMITTED estado.
Aunque las aplicaciones pueden realizar escrituras una vez que se devuelve canWrite:
true, las operaciones que requieren bloqueos exclusivos, como la creación de índices, solo pueden proceder después de que se complete la conversión del índice. Además, las operaciones de guardar pueden experimentar una mayor latencia durante este tiempo debido a la contención de recursos en competencia.