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"
},
"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 true, 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.

  • Se vocĂȘ iniciar o mongosync com enableUserWriteBlocking definido como false, certifique-se de desabilitar as gravaçÔes. Por exemplo, execute o comando setUserWriteBlockMode no cluster de origem:

    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.

Depois de concluir esta etapa, mongosync blocos de gravaçÔes no cluster de origem.

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 true, mongosync bloqueia as gravaçÔes no cluster de origem depois de concluir essa etapa.

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.

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.