mongosync
. Leia a documentação atual para obter orientações atualizadas sobre mongosync
e instruções sobre como atualizar para a versão mais recente.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.
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. Os camposlagTimeSeconds
em ambos os documentos devem estar próximos de0
e os camposphase
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.
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.
Aguarde todas as transações no cluster de origem confirmarem ou cancelarem.
Se você iniciar
mongosync
comenableUserWriteBlocking
definido comotrue
,mongosync
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 desabilitar as gravações. Por exemplo, execute o comando no cluster desetUserWriteBlockMode
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.
Envie uma solicitação de confirmação para mongosync
.
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
.
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
.
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.
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.
Se você bloqueou manualmente as gravações no cluster de destino usando setUserWriteBlockMode
, 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.
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.
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
.