Introdução
Um guia passo a passo para te ajudar a abrir, configurar e rodar uma Live Migration no NoSqlStudio — a tela que move dados para o MongoDB a partir de outra origem (por exemplo uma conta do Cosmos DB) com downtime mínimo. Siga do Passo 1 até o fim, em ordem. Cada passo diz o que fazer e o que você vai ver.
Como ler este manual
Cada passo tem:
- Faça — a ação exata (abrir a tela, definir uma origem, rodar o assessment).
- Veja — o que deve acontecer na tela. Esse é o seu “passou / falhou”.
- Por quê — contexto adicional, só quando ajuda (pule se estiver com pressa).
Antes de começar
Conceito
O que é uma migração ao vivo (online)
Uma migração ao vivo move seus dados enquanto o banco de origem continua atendendo tráfego. Em vez de um dump-and-restore de uma vez só — onde você para as escritas, exporta, importa e só então faz a virada — a Live Migration faz uma cópia bulk completa e depois mantém o destino sincronizado com as escritas em andamento (CDC) até você fazer o cutover. Isso reduz o downtime à breve janela de cutover, em vez de à cópia inteira.
Atenção
Ensaie antes de migrar de verdade
Um cutover real redireciona uma aplicação de produção para um novo banco. Rode todo este walkthrough contra dados de teste e um destino descartável primeiro, para que os passos e suas verificações de “Veja” já sejam familiares antes de qualquer coisa importar.
Você vai precisar de:
- 1Uma conexão ativa no NoSqlStudio — a Live Migration roda em cima de uma conexão ativa, então conecte primeiro.
- 2Uma origem acessível (por exemplo uma conta do Cosmos DB, ou outro MongoDB) e um destino MongoDB (self-hosted ou Atlas) no qual você consiga escrever.
- 3Acesso suficiente dos dois lados: leitura na origem, e escrita no banco de destino para o qual você está migrando.
Tempo estimado para o walkthrough completo: ~15 minutos.
Abrir e conectar
Abra uma conexão e traga a tela da Live Migration.
Conecte-se a um deployment
Conecte o NoSqlStudio a um deployment ativo usando sua connection string — por exemplo mongodb+srv://<user>:<password>@<cluster-host>/.
A conexão abre e aparece na barra lateral.
A Live Migration faz parte das ferramentas DataOps de Schema & Data, e todas elas precisam de uma conexão ativa para funcionar.
Abra a Live Migration
Na tela Home abra o card Schema & Data, ou use o menu Tools ▸ Schema & Data ▸ Live Migration (atalho de teclado Ctrl+Alt+Y).
A tela 🚚 Live Migration abre por conta própria — diferente de Copy, Compare e Data Mask, ela não faz parte do container Data Operations; é uma tela própria e dedicada.
Conceito
Por que uma tela própria
Copy, Compare e Mask são operações de uma passada que ficam juntas num container Data Operations com abas. Uma migração é um job mais longo e multi-fase — assess → bulk → CDC sync → cutover — então ganha uma tela própria para mostrar o progresso em cada fase.
Configurar origem e destino
Escolha a origem
Na configuração de origem, escolha de onde vêm os dados — por exemplo uma conexão do Cosmos DB.
A origem é definida e a Live Migration a exibe como a origem da migração.
A Live Migration foi feita para mover dados para dentro do MongoDB a partir de outro sistema; o Cosmos DB é uma origem comum, mas o mesmo fluxo se aplica a qualquer origem suportada.
Escolha o destino
Na configuração de destino, escolha o deployment MongoDB para o qual você está migrando — seu cluster self-hosted ou um cluster Atlas.
O destino é definido, e agora você tem as duas pontas — origem e destino — conectadas.
Conceito
Definindo o escopo
Antes de rodar qualquer coisa, seja deliberado sobre o que você está migrando — a instância inteira, um único banco ou coleções específicas. Um escopo estreito e bem compreendido é mais fácil de avaliar, mais rápido de copiar e mais simples de verificar depois do cutover.
Assess
Rode o assessment
Com origem e destino configurados, rode o assessment — a primeira fase do fluxo.
A Live Migration produz um relatório do que vai migrar e de quaisquer achados de compatibilidade entre a origem e o destino.
Leia os achados
Revise o assessment antes de seguir: ele te diz quais bancos e coleções estão no escopo e expõe qualquer coisa que possa precisar de atenção no caminho para dentro do MongoDB.
Conceito
Por que avaliar primeiro
O assessment é um ensaio de entendimento: ele inventaria o que vai se mover e sinaliza incompatibilidades antes de você copiar um único byte. Achar um problema no relatório é barato; achá-lo no meio de um bulk de vários gigabytes não é.
Bulk load
Inicie a cópia bulk
Inicie a fase bulk para copiar os dados existentes da origem para o destino.
O progresso ao vivo aparece enquanto a cópia bulk roda — você consegue acompanhar o avanço pelos dados.
Acompanhe até concluir
A fase bulk trabalha pelos dados no escopo e reporta seu progresso até a conclusão.
Conceito
O que significa bulk
O bulk é a cópia completa inicial — um snapshot point-in-time de tudo que está atualmente no escopo, movido para o destino. É o trabalho pesado da migração. As escritas que chegam na origem enquanto (e depois que) o bulk roda são tratadas pela próxima fase, não por esta.
CDC sync
Mantenha o destino em sincronia com a origem enquanto a aplicação ainda está escrevendo.
Acompanhe o CDC sync
Depois que o bulk conclui, acompanhe a fase CDC sync enquanto ela transmite as mudanças em andamento da origem para o destino.
O destino se mantém em sincronia com a origem: inserts, updates e deletes que continuam acontecendo na origem são aplicados continuamente no destino, e o lag entre eles tende a zero.
Conceito
O que é o CDC
CDC — change data capture — observa o stream de mudanças da origem e o reaplica no destino. O bulk te dá um snapshot; o CDC mantém esse snapshot atualizado, para que a aplicação possa continuar ao vivo na origem o tempo todo em que a cópia e o catch-up acontecem.
Mantenha a origem acessível
Cutover
Faça o cutover quando o lag estiver ~zero
Quando o lag do CDC estiver em ou perto de zero, orquestre o cutover — a fase final — para virar a aplicação para o destino.
A migração completa o cutover e o destino passa a ser o banco que sua aplicação usa agora.
Conceito
Minimizando o downtime
O cutover é o único momento que precisa de uma pausa real. Como o bulk e o CDC já fizeram o trabalho, a origem e o destino estão quase idênticos na hora de virar — então o downtime é só a curta janela de virada, e não a cópia inteira. Esse é todo o ponto de uma migração online.
Verifique o resultado
Depois do cutover, verifique se o destino bate com a origem usando o Compare Databases (Ctrl+Alt+Shift+C) — selecione os dois lados e revise o diff estrutural.
O Compare reporta as diferenças (idealmente nenhuma de substância) para que você possa confirmar que a migração trouxe tudo o que você esperava.
Uma migração só está pronta quando você consegue provar que o destino está certo. O Compare te dá essa evidência em vez de um palpite.
Limpeza (quando terminar)
Pare ou feche a migração quando o cutover estiver completo (ou para abandonar um ensaio), depois feche a tela da Live Migration.
O job de migração termina e a tela fecha de forma limpa.
Atenção
Um cutover real é uma mudança de produção — ele reaponta uma aplicação ao vivo para um novo banco. Ensaie todo o fluxo em dados de teste primeiro, e só rode o cutover de produção depois que cada “Veja” deste manual tiver batido no seu ensaio.
Resumo do que você validou
| Etapa | Recurso |
|---|---|
| 1 | Abrir a Live Migration em tela própria (Ctrl+Alt+Y) sobre uma conexão ativa |
| 2 | Configurar a origem (ex.: Cosmos DB) e o destino MongoDB/Atlas, e definir um escopo |
| 3 | Rodar o assessment e ler seus achados de compatibilidade antes de copiar |
| 4 | Iniciar o bulk load e acompanhar o progresso da cópia completa inicial |
| 5 | Acompanhar o CDC sync mantendo o destino atualizado com as escritas em andamento na origem |
| 6 | Orquestrar o cutover com lag ~zero e verificar com o Compare Databases |