VocĂȘ pode finalizar uma migração e transferir o volume de trabalho do aplicação do cluster de origem para o de destino usando o processo de substituição do mongosync .
mongosync deve permanecer ativo até atingir o estado escalado. Isso permite que mongosync sincronize quaisquer gravaçÔes adicionais que ocorram durante a migração.
Observação
Antes de mudar o volume de trabalho do aplicação para o cluster de destino, vocĂȘ deve sempre verificar uma sincronização bem-sucedida. Para mais informaçÔes, consulte Verificar TransferĂȘncia de Dados.
Passos
Verifique o status do mongosync.
Ligue para o endpoint de progresso para determinar o status de mongosync antes de iniciar o processo de cutover. Certifique-se de que o status do processo mongosync indique os seguintes valores:
canCommitétrue.lagTimeSecondsé pequeno (perto de0).Se
lagTimeSecondsnão estiver próximo de0quando a transição começar, a transição poderå levar muito tempo.Ao usar o Verificador incorporado, verifique
verification.sourceosverification.destinationdocumentos de devolução e. Os camposlagTimeSecondsem ambos os documentos devem estar próximos de0e os camposphasedevem mostrar"stream hashing".Se o verificador não estiver na fase de hash de fluxo, o processo de corte pode levar muito tempo.
O exemplo a seguir retorna o status do processo de sincronização.
Solicitar
curl localhost:27182/api/v1/progress -XGET
Resposta
{ "progress": { "state":"RUNNING", "canCommit":true, "canWrite":false, "info":"change event application", "lag": { "overallLagSeconds": 0, "crudLagSeconds": 0, "ddlLagSeconds": null }, "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 }
Pare todas as operaçÔes de gravação nas coleçÔes sincronizadas na origem.
Aguarde todas as transaçÔes no cluster de origem confirmarem ou cancelarem.
mongosyncgerencia o bloqueio de gravação com base em sua configuração de migração. Para saber mais, consulte Bloqueio de escrita.Se o
mongosyncusar sincronização filtrada, nĂŁo serĂĄ necessĂĄrio desabilitar as gravaçÔes em todo o cluster de origem. No entanto, vocĂȘ deve garantir que vocĂȘ interrompa as operaçÔes de gravação para as coleçÔes que o filtro inclui.
Envie uma solicitação de confirmação para mongosync.
Se vocĂȘ iniciar mĂșltiplas instĂąncias do mongosync para sua migração, vocĂȘ deverĂĄ emitir uma solicitação de confirmação para cada instĂąncia do mongosync.
Solicitar
curl localhost:27182/api/v1/commit -XPOST --data '{ }'
Resposta
{"success":true}
Observação
Depois de enviar uma solicitação commit , chame o endpoint progress para garantir que o estado mongosync seja COMMITTING ou COMMITTED.
Se o cluster de origem tiver ConfiguraçÔes de Query Persistentes (PQS), vocĂȘ deverĂĄ migrar manualmente o PQS para o cluster de destino.
Na configuração padrão, mongosync bloqueia as gravaçÔes no cluster de origem depois de concluir esta etapa.
Se mongosync falhar durante essa etapa, talvez seja necessårio desbloquear manualmente as gravaçÔes no cluster de origem executando o seguinte comando:
db.adminCommand( { setUserWriteBlockMode: 1, global: false } )
Aguarde atĂ© que vocĂȘ possa executar gravaçÔes no cluster de destino.
Chame o ponto de extremidade progress para determinar se canWrite Ă© true. Se canWrite for false, aguarde atĂ© que progress mostre que canWrite Ă© true. Se vocĂȘ estiver executando vĂĄrias instĂąncias do mongosync, verifique apenas se canWrite Ă© verdadeiro no primeiro processo mongosync. O status canWrite de qualquer processo mongosync subsequente nĂŁo Ă© vĂĄlido.
curl -sS localhost:27182/api/v1/progress -XGET | jq ".progress.canWrite"
true
Verifique a transferĂȘncia de dados.
Verifique a sincronização bem-sucedida de dados da origem para o cluster de destino.
Para obter mais informaçÔes, consulte Verificar a fonte de dados.
Se vocĂȘ bloqueou manualmente as gravaçÔes no cluster de destino usando setUserWriteBlockMode, habilite as gravaçÔes do aplicativo no cluster de destino.
Para habilitar gravaçÔes, atualize setUserWriteBlockMode:
db.adminCommand( { setUserWriteBlockMode: 1, global: false } )
Em seguida, transfira o volume de trabalho do aplicação para o cluster de destino.
Comportamento
canWrite e Committed
mongosync permite gravaçÔes no cluster de destino em um estågio anterior ao estado COMMITTED.
VocĂȘ pode gravar no destino depois que /progress informa canWrite: true ou quando o estado for COMMITTED. Para saber mais sobre o bloqueio de escrita, consulte Bloqueio de escrita. Se vocĂȘ estiver executando vĂĄrias instĂąncias de mongosync, use somente o status canWrite do primeiro processo mongosync.
Na sincronização inicial, o mongosync replica Ăndices Ășnicos no cluster de origem como Ăndices nĂŁo exclusivos no cluster de destino. Durante o commit, os Ăndices nĂŁo exclusivos relevantes no cluster de destino sĂŁo definidos como prepareUnique. Quando isso Ă© feito, o ponto de extremidade /progress começa a retornar canWrite: true. As collections com Ăndices prepareUnique rejeitam novos documentos que violam a restrição de Ăndice Ășnico . mongosync entĂŁo converte os Ăndices prepareUnique em Ăndices Ășnicos. Quando isso Ă© feito, mongosync muda de estado para COMMITTED.
Observação
A conversĂŁo de Ăndices prepareUnique em Ăndices Ășnicos pode consumir muitos recursos ao sincronizar grandes collections. Isso pode resultar em um longo tempo entre o endpoint /progress retornando canWrite: true e mongosync atingindo o estado COMMITTED.
Embora os aplicativos possam emitir gravaçÔes quando canWrite: true for retornado, as operaçÔes que exigem bloqueios exclusivos, como compilaçÔes de Ăndice, podem prosseguir somente apĂłs a conclusĂŁo da conversĂŁo do Ăndice. AlĂ©m disso, as operaçÔes de gravação podem sofrer um aumento da latĂȘncia durante esse perĂodo devido Ă contenção de recursos da concorrĂȘncia.