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 Committed. 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 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
  • Wait for all transactions on the source cluster to either commit or abort.

  • mongosync ativa o bloqueio de gravação somente de destino por padrão. Você pode habilitá-lo explicitamente iniciando mongosync com enableUserWriteBlocking definido como "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.

  • Se você iniciar mongosync o enableUserWriteBlocking com definido "none" como, certifique-se de desabilitar as gravações. Por exemplo, execute o setUserWriteBlockMode comando 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

Ligue para o ponto de extremidade progress para determinar se canWrite é true. Se canWrite for false, aguarde até que progress mostre que canWrite é true.

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 mongosync o com bloqueio de gravação usando a enableUserWriteBlocking opção 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.

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.