Para agentes de IA: um Ă­ndice de documentação estĂĄ disponĂ­vel em https://www.mongodb.com/pt-br/docs/llms.txt — as versĂ”es de markdown de todas as pĂĄginas estĂŁo disponĂ­veis anexando .md a qualquer caminho de URL.
Menu Docs

Finalize o processo de transição

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.

1

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 de 0).

    Se lagTimeSeconds não estiver próximo de 0 quando a transição começar, a transição poderå levar muito tempo.

  • Ao usar o Verificador incorporado, verifique verification.source os verification.destination documentos de devolução e. Os campos lagTimeSeconds em ambos os documentos devem estar prĂłximos de 0 e os campos phase devem 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.

curl localhost:27182/api/v1/progress -XGET
{
"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
}
2
  • Aguarde todas as transaçÔes no cluster de origem confirmarem ou cancelarem.

  • mongosync gerencia o bloqueio de gravação com base em sua configuração de migração. Para saber mais, consulte Bloqueio de escrita.

  • Se o mongosync usar 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.

3

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.

curl localhost:27182/api/v1/commit -XPOST --data '{ }'
{"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
}
)
4

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
5

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.

6

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.

7

Quando a resposta de progresso do mongosync indicar que o estado do mongosync Ă© COMMITTED, o processo de cutover estarĂĄ concluĂ­do.

curl -sS localhost:27182/api/v1/progress -XGET | jq ".progress.state"
"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.