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",
"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 habilita o bloqueio de gravação somente de destino por padrĂŁo. VocĂȘ pode habilitĂĄ-lo explicitamente começando mongosync com enableUserWriteBlocking configurado para "destinationOnly". mongosync apenas bloqueia gravaçÔes no destino e as desbloqueia logo antes de canWrite ser definido como true.

  • Se vocĂȘ iniciar mongosync com enableUserWriteBlocking definido como "sourceAndDestination", mongosync bloquearĂĄ todas as operaçÔes de gravação no cluster de destino e as desbloquearĂĄ logo antes de canWrite ser definido como true. mongosync bloqueia gravaçÔes na fonte depois de chamar /commit.

  • If you start mongosync with enableUserWriteBlocking set to "none", ensure that you disable writes. For example, run the setUserWriteBlockMode command on the source cluster:

    db.adminCommand( {
    setUserWriteBlockMode: 1,
    global: true
    } )
  • 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.

Se vocĂȘ definiu anteriormente enableUserWriteBlocking como sourceAndDestination, mongosync bloqueia as gravaçÔes no cluster de origem depois de concluir essa etapa.

If you previously set enableUserWriteBlocking to sourceAndDestination and mongosync crashes during this step, you must manually unblock writes on the source cluster by using setUserWriteBlockMode.

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

To enable writes, update setUserWriteBlockMode:

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

Em seguida, transfira o volume de trabalho do aplicação para o cluster de destino.

Se vocĂȘ iniciou o mongosync com bloqueio de gravação usando a opção enableUserWriteBlocking no endpoint /start, nĂŁo serĂĄ necessĂĄrio concluir esta etapa.

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.

Se vocĂȘ definir enableUserWriteBlocking como "sourceAndDestination" ou "destinationOnly", ou o verificador estiver ativado, poderĂĄ gravar no destino depois que /progress reportar canWrite: true. Caso contrĂĄrio, aguarde atĂ© que o estado seja COMMITTED. 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.

Avalie esta pĂĄgina