Finalize o processo de transição
Nesta página
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 domongosync .
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
processo .
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
lagTimeSeconds
não estiver próximo de0
quando a transição começar, a transição poderá levar muito tempo.Ao usar o Verificador incorporado, verifique
verification.source
osverification.destination
documentos de devolução e. OslagTimeSeconds
campos em ambos os documentos devem estar próximos0
de e osphase
campos devem mostrar"stream hashing"
.Se
/commit
for chamado e os valores não estiverem próximos de0
ou se o verificador não estiver na fase de hash de fluxo, o processo de substituição poderá 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", "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 }
Pare todas as operações de gravação nas coleções sincronizadas na origem.
Se você iniciou o
mongosync
comenableUserWriteBlocking
definido comotrue
, omongosync
bloqueará todas as operações de gravação em todo o cluster de origem durante o commit (etapa 4) para você.Se você não iniciou
mongosync
comenableUserWriteBlocking
, certifique-se de que as gravações estejam desativadas. Por exemplo, execute o comandosetUserWriteBlockMode
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. Mas você deve garantir que as operações de gravação sejam interrompidas para as coleções incluídas pelo filtro.
Envie uma solicitação de confirmação para mongosync
.
Se você iniciou várias instâncias mongosync
para sua migração, deverá emitir uma solicitação de confirmação para cada instância 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
.
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.
Habilite as gravações do aplicação 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.
Ligue para o progress
ponto de extremidade para determinar o status do mongosync
processo .
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"
Comportamento
canWrite e 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
.