Como migrar bilhões de linhas sem parar a operação

O medo não é o volume, é a operação parar no meio#

Quando alguém diz que precisa migrar bilhões de linhas, a primeira reação costuma ser sobre tamanho: quanto de banco, quantas horas de carga, qual instância aguenta. Mas o problema real quase nunca é o volume em si. É que essa base está viva. Tem pedido entrando, nota sendo emitida, saldo mudando enquanto você tenta copiar tudo. Saber como migrar bilhões de linhas sem parar a operação é, antes de qualquer coisa, saber lidar com o fato de que a fonte não fica parada esperando você terminar.

A tentação de "desligar tudo no fim de semana, copiar e religar" existe porque é simples de imaginar. Mas não escala: em volumes grandes a cópia não cabe na janela de manutenção, e mesmo que coubesse você estaria apostando o negócio inteiro sem rede de segurança. Depois de várias migrações de porte, a nossa opinião é direta: migração de grande volume não é um evento, é um processo com fases separadas. Este artigo mostra quais são elas e onde estão os riscos que ninguém gosta de admitir.

Separe a carga histórica da captura de mudanças#

O primeiro princípio que muda tudo: a migração de grande volume separa a carga inicial, o chamado backfill, da captura de mudanças que acontecem durante a transição. São dois problemas diferentes, com ferramentas diferentes, e tratá-los como um só é a origem da maioria dos desastres.

O backfill é a cópia do que já existe: bilhões de linhas que estavam lá antes de você começar. Essa parte é grande, mas tem uma vantagem enorme: é imutável para efeito da migração. O passado não muda, então você lê no seu ritmo, em lotes, sem pressão de tempo real.

A captura de mudanças, ou CDC (Change Data Capture), cuida do que muda enquanto o backfill roda e depois dele. Cada insert, update e delete que a operação gera precisa ser aplicado no destino, senão ele nasce desatualizado. O CDC lê o log de transações da origem, o binlog no MySQL, o WAL no PostgreSQL, o transaction log no SQL Server, e transforma cada alteração em um evento que o destino consome.

A imagem mental é a de uma escada rolante: o backfill copia os degraus já montados, o CDC copia os que continuam surgindo enquanto você trabalha. Quando os dois se encontram, origem e destino ficam idênticos, e você tem uma migração de verdade sem congelar a operação. Quem quer ver como montamos esse pipeline de ponta a ponta encontra nossa engenharia de dados: a orquestração dessas duas trilhas é onde mora boa parte do trabalho.

As fases de uma migração que não derruba o negócio#

Migração séria tem sequência: cada fase reduz o risco da seguinte. Pular etapa é soldar sem apagar o fogo.

Fase	O que acontece	Objetivo
1. Preparação	Mapeia esquema, chaves e dependências. Habilita o CDC na origem	Saber o terreno antes de escavar
2. Backfill	Copia o histórico em lotes particionados, sem tocar na operação	Levar o grosso do dado para o destino
3. CDC contínuo	Aplica no destino as mudanças capturadas desde o início do backfill	Fechar o intervalo entre passado e presente
4. Sincronização	Origem e destino alinhados em tempo quase real	Manter o destino pronto para assumir
5. Corte	Janela curta em que a escrita passa para o destino	Trocar o sistema de verdade
6. Validação	Compara paridade e monitora o novo ambiente	Provar que migrou certo antes de desligar a origem

O corte, a parte que todo mundo teme, é a mais curta de todas. Não por sorte, e sim porque o trabalho pesado foi feito antes: quando você chega nele, quase tudo já está no destino.

Fase de preparação: onde os riscos ficam baratos#

Antes de copiar qualquer linha, conheça o esquema, as chaves primárias, as estrangeiras e as dependências entre tabelas. Sem chave primária confiável, o CDC não sabe qual linha atualizar no destino, e a migração vira loteria. Aqui também se habilita a captura de mudanças na origem, o que exige configuração e negociação com o time de banco: ligar o CDC tem custo de armazenamento e de retenção de log.

É aqui que você decide o particionamento do backfill: uma coluna de data, um intervalo de identificadores, qualquer critério que corte a tabela gigante em pedaços processáveis. Errar aqui é caro depois.

Backfill em lotes particionados torna o volume administrável#

Ninguém copia bilhões de linhas em uma transação só: isso trava a origem, estoura o log e, na primeira falha, você recomeça do zero. A técnica é quebrar a carga em lotes particionados, faixas de valores que você processa uma de cada vez.

O particionamento resolve três coisas de uma vez:

1. Paralelismo. Vários lotes rodam simultaneamente, cada um em uma faixa distinta, respeitando o limite que a origem aguenta.
2. Retomada. Se o lote da faixa X falhar, você reprocessa só ela. As outras já concluídas continuam válidas. Nada de recomeçar tudo.
3. Controle de pressão. Você regula a velocidade para não sufocar o banco de produção, que continua respondendo enquanto o backfill trabalha por baixo.

A regra de ouro do backfill é a idempotência: rodar o mesmo lote duas vezes dá o mesmo resultado. Se reprocessar duplica linha, você não tem migração, tem bomba-relógio. Na prática, carregue com upsert por chave, nunca com insert cego.

Um ponto honesto: o backfill compete por recursos com a operação real. Ler bilhões de linhas de um banco vivo gera carga, por isso ele roda com throttling, em horários de menor movimento, monitorando o impacto na origem. Não existe backfill grande sem custo de I/O, e sim backfill bem regulado.

CDC e sincronização contínua mantêm origem e destino alinhados#

Enquanto o backfill copia o passado, a operação segue gerando presente. O CDC captura cada mudança e a enfileira. Aqui está a sutileza que separa quem já fez migração de quem só leu: a sobreposição entre backfill e CDC.

O CDC precisa começar a capturar antes de o backfill começar, marcando um ponto no log de transações. Assim, qualquer alteração feita durante a cópia do histórico também é registrada. Quando o backfill acaba, você aplica os eventos de CDC acumulados, e o destino "alcança" a origem. A partir daí, a sincronização é contínua: cada nova mudança chega ao destino em segundos.

Há duas estratégias para o alinhamento na reta final:

Estratégia	Como funciona	Quando faz sentido
Sincronização por CDC	O destino consome o fluxo de mudanças da origem de forma assíncrona	Padrão para a maioria dos casos, menos intrusiva
Dupla escrita	A aplicação grava ao mesmo tempo na origem e no destino	Quando o destino precisa estar consistente na hora e você aceita mexer no código

A dupla escrita parece elegante, mas é mais perigosa do que aparenta. Ela exige alterar a aplicação para gravar nos dois lados e tratar o caso de uma escrita ter sucesso e a outra falhar. Sem cuidado, você cria divergência em vez de resolver. A recomendação, na maioria dos projetos, é preferir CDC e usar dupla escrita só com justificativa forte e um plano claro para as falhas parciais.

A meta da sincronização é chegar ao corte com o destino tão perto da origem que a diferença seja de segundos, não de horas. Esse alinhamento apertado é o que permite a janela de corte curta.

A janela de corte curta é a recompensa do trabalho feito antes#

O corte é o momento em que o sistema de verdade deixa de ser a origem e passa a ser o destino. Como quase tudo já foi migrado e a sincronização está a segundos, a janela pode ser muito curta. O roteiro típico é:

1. Congelar a escrita na origem. Por alguns instantes, a aplicação para de gravar, com um breve modo de leitura ou uma pausa mínima, conforme o apetite de risco.
2. Drenar o CDC. Aplicar no destino os últimos eventos pendentes, até a fila zerar. Origem e destino ficam idênticos.
3. Validar a paridade. Rodar as checagens rápidas que confirmam que os dois lados batem.
4. Redirecionar a aplicação. Apontar as conexões para o destino.
5. Reabrir a escrita. Agora no destino.

Migração amadora tem corte longo porque deixou trabalho para a última hora; a bem feita chega com quase nada a fazer, e cabe em minutos em vez de um fim de semana. Com franqueza: "sem parar a operação" costuma significar uma indisponibilidade mínima e controlada no corte, não zero absoluto. Prometer zero downtime sem ressalvas é onde muita gente mente.

Validação de paridade prova que a migração está correta#

Migrou não é o mesmo que migrou certo. Antes de desligar a origem, prove que o destino é cópia fiel. Essa prova se chama validação de paridade, e compara os dois lados de formas complementares:

• Contagem de linhas. O número de registros por tabela bate entre origem e destino. É o teste mais básico e o primeiro a rodar.
• Somas de controle. Totais de colunas numéricas relevantes, saldos, valores financeiros, quantidades, precisam ser idênticos. Contagem igual com soma diferente denuncia dado corrompido no meio do caminho.
• Amostragem por chave. Comparação linha a linha de registros escolhidos, incluindo os mais recentes e casos de borda.
• Reconciliação de negócio. Relatórios-chave rodados nos dois ambientes devem produzir o mesmo resultado. É o que a operação vai olhar.

A validação roda ao longo do processo e, principalmente, no corte, quando a fila de CDC zerou. Se a paridade não fecha, você não corta. Um número que não bate é sinal para acionar o rollback, não para "seguir e ver no que dá". Para essa reconciliação, é comum apoiar a conferência em Power BI, comparando os mesmos indicadores nos dois ambientes lado a lado.

O plano de rollback existe para o dia em que algo dá errado#

Toda migração competente tem resposta pronta para "e se der errado depois do corte?". Essa resposta é o plano de rollback, e não é opcional: é o que separa uma migração profissional de uma aposta.

O segredo é manter a origem viva e íntegra por um período após o corte, sem desligá-la de imediato. Enquanto ela está lá, você tem para onde voltar. Se um problema grave aparecer nas primeiras horas, você reaponta a aplicação para a origem, e a operação continua com um susto em vez de um desastre.

Para que o rollback funcione, três condições precisam estar de pé:

1. A origem intacta. Nada de derrubar o banco antigo no dia do corte. Ele fica de reserva pelo tempo combinado.
2. Um gatilho claro. Critérios objetivos que definem quando voltar atrás, decididos antes, não no calor do momento com todo mundo nervoso.
3. O caminho de volta ensaiado. Se durante o corte houve dupla escrita ou CDC reverso, o destino recebeu dados novos, e voltar exige levá-los de volta à origem ou aceitar a perda de forma consciente. Isso precisa estar no papel.

Só se desliga a origem depois que o destino provou estabilidade e a paridade se manteve pelo período combinado. Antes disso, desligar é queimar a única saída de emergência. Já vimos times apagarem a origem cedo demais e pagarem semanas por isso. Não vale a economia.

Perguntas frequentes#

Dá para migrar bilhões de linhas realmente sem nenhum downtime? O mais honesto é falar em janela de corte curta e controlada, não em zero absoluto. Backfill e CDC eliminam a parada durante quase todo o processo, mas o instante do corte costuma ter uma indisponibilidade mínima, de segundos a poucos minutos. Quem promete zero sem ressalva está escondendo o corte.

Qual a diferença entre backfill e CDC? O backfill copia o histórico que já existe, uma carga grande e imutável que você processa em lotes no seu ritmo. O CDC captura as mudanças que acontecem durante e depois do backfill, lendo o log de transações da origem. Um cuida do passado, o outro do presente; juntos, deixam origem e destino idênticos.

Preciso de dupla escrita na aplicação? Na maioria dos casos, não. A sincronização por CDC é menos intrusiva e não exige mexer no código da aplicação. Dupla escrita só se justifica quando o destino precisa estar consistente na hora e há um plano sólido para as falhas parciais, quando uma escrita passa e a outra não.

Como saber se a migração ficou correta? Pela validação de paridade: contagem de linhas por tabela, somas de controle de colunas numéricas, amostragem linha a linha por chave e reconciliação dos relatórios de negócio. A checagem roda ao longo do processo e no corte. Se algum número não bate, você não corta, aciona o rollback.

Quanto tempo devo manter o banco de origem depois do corte? Pelo período em que o destino ainda precisa provar estabilidade, que varia com o risco do negócio. A regra é não desligar a origem enquanto ela for a saída de emergência: só se encerra quando a paridade se manteve e o novo ambiente rodou sem incidentes pelo tempo combinado.

Isso funciona para migrar entre nuvens ou entre ferramentas diferentes? Sim. A estratégia de backfill mais CDC mais corte curto é agnóstica de destino. Vale para trocar de banco, mudar de nuvem ou consolidar em uma plataforma analítica moderna. Se o alvo for o ecossistema Microsoft, vale ler nossa visão sobre o Microsoft Fabric e conhecer nossos serviços de analytics avançado.

Como migrar bilhões de linhas sem parar a operação é questão de método#

Não é questão de ter a máquina mais potente, e sim de método: separar o backfill do CDC, carregar o histórico em lotes particionados e idempotentes, manter origem e destino alinhados com sincronização contínua, chegar ao corte com janela curta, provar tudo com validação de paridade e ter um plano de rollback pronto. Volume grande com processo certo é trabalhoso, mas previsível; sem processo, é aposta.

Se você tem uma base viva e crítica para migrar e não pode se dar ao luxo de parar, fale com a gente. A Fynx desenha e executa esse tipo de migração, com o rollback sempre na mesa.