Migração de banco sem downtime: replicação lógica e cutover

Migrar banco de dados é a operação de maior risco concentrado que uma equipe de infraestrutura executa. Todo o resto do sistema pode ser recriado; o banco é o único lugar onde o dado existe. E, ao contrário de quase tudo em tecnologia, o rollback tem uma janela que se fecha: depois que a aplicação escreve no destino, voltar significa perder o que foi escrito.

A boa notícia é que o método é conhecido e sistemático. Migração de banco dá errado por falta de ensaio, quase nunca por falta de conhecimento técnico.

Por que você está migrando

A razão muda o método, então defina primeiro:

Os três primeiros compartilham o mesmo roteiro. O quarto é um projeto de software, não de infraestrutura, e não é o assunto deste texto.

Os dois caminhos

Parada e cópia. Para a aplicação, copia tudo, sobe no destino. Simples, previsível e com janela proporcional ao volume: um banco de 2 TB pode significar muitas horas parado.

É a escolha certa quando a janela cabe. E vale medir antes de descartar — para bancos pequenos, a complexidade da alternativa não compensa.

Replicação lógica. O destino recebe uma cópia inicial e passa a receber as alterações continuamente, enquanto a origem segue em produção. Quando as duas estão em sincronia, você faz o corte em minutos.

É o caminho para volumes que não cabem na janela, e o único que permite migrar entre versões diferentes — porque a replicação lógica transmite mudanças de dado, não blocos físicos, e por isso atravessa fronteiras de versão.

Antes de tocar em qualquer coisa

Quatro itens que decidem o resultado:

1. Backup completo da origem, restaurado e validado em outro lugar. Não o último backup de rotina — um backup feito para esta migração, verificado.
2. Inventário de tudo que aponta para o banco. Aplicações, relatórios, integrações, tarefas agendadas, scripts de alguém, ferramenta de BI, painel esquecido. É a lista que sempre tem uma surpresa, e a surpresa aparece dias depois do corte.
3. Inventário do que não é dado: usuários e permissões, parâmetros do servidor, extensões e versões, tarefas agendadas dentro do banco, certificados, regras de acesso por rede.
4. RPO e RTO acordados por escrito com quem responde pelo negócio.

O item 2 merece um esforço real. A forma mais confiável de montá-lo é observar as conexões ativas ao banco por um período representativo — incluindo o fechamento do mês, quando aparecem integrações que rodam uma vez por ciclo.

O roteiro com replicação lógica

1. Preparar o destino com a mesma configuração relevante: parâmetros, extensões, versões compatíveis.
2. Migrar o esquema — apenas a estrutura, sem os dados.
3. Criar a replicação e deixar a carga inicial acontecer. Pode levar horas em base grande; ela ocorre com a origem em produção.
4. Acompanhar o atraso até ele estabilizar em segundos.
5. Validar continuamente: contagem de linhas por tabela, somas de verificação em colunas-chave, amostragem comparada.
6. Criar os objetos que a replicação lógica não leva — e essa lista é específica de cada banco, mas costuma incluir índices adicionais, sequências, e objetos criados após o início da replicação.
7. Ensaiar o corte em ambiente de homologação, com o roteiro completo e cronômetro.
8. Executar o corte.
9. Manter a origem intacta por um período definido.

O que a replicação lógica não leva

A lacuna mais perigosa, porque é silenciosa — tudo parece certo até alguém tentar usar.

• Sequências e contadores não são replicados no PostgreSQL. Se você não ajustá-los antes de liberar escrita no destino, a primeira inserção colide com chave existente. É o erro mais comum e mais constrangedor.
• Comandos de estrutura (criar tabela, alterar coluna) geralmente não são replicados. Qualquer migração de esquema durante a janela precisa ser aplicada nos dois lados.
• Tabelas sem chave primária podem não ser replicadas, ou exigir configuração adicional.
• Objetos grandes guardados fora das tabelas, dependendo do banco.
• Usuários, permissões e configuração do servidor.

Congele mudanças de esquema durante a janela de migração. É uma regra simples que evita a maior parte dos problemas dessa lista.

O corte

A parte que precisa estar escrita minuto a minuto, com responsável por linha:

1. Comunicar — equipe, suporte e, se houver impacto perceptível, clientes.
2. Colocar a aplicação em modo somente leitura, ou pará-la. É o começo da janela real.
3. Aguardar o atraso de replicação chegar a zero. Confirme; não presuma.
4. Parar a replicação.
5. Ajustar as sequências no destino.
6. Rodar a validação final: contagens, somas de verificação, últimas transações presentes.
7. Redirecionar a aplicação — por DNS com tempo de vida baixo, por proxy ou por configuração.
8. Subir a aplicação e executar o roteiro de fumaça: login, leitura, escrita, relatório, integração.
9. Observar por um período com alerta reforçado.
10. Manter a origem desligada mas intacta pelo prazo definido.

O item 7 merece preparação: reduza o tempo de vida do registro DNS com antecedência, dias antes. Tempo de vida alto significa clientes conectando no endereço antigo por horas depois do corte — e, se a origem ainda aceita escrita, você tem dado sendo gravado em dois lugares.

Por isso o item 2 é crítico: a origem precisa parar de aceitar escrita antes de o destino começar. Escrita nos dois lados é a pior coisa que pode acontecer numa migração, e é a mais difícil de consertar.

O plano de volta

Quase ninguém escreve, e é o que separa migração profissional de aposta.

Defina antes:

• Até que ponto o rollback é simples? Enquanto a aplicação não escreveu no destino, basta redirecionar de volta. Depois disso, voltar significa perder as escritas ou reconciliá-las manualmente.
• Qual o critério de abortar? Escrito, objetivo: "se a validação não passar", "se o corte ultrapassar X minutos", "se a taxa de erro exceder Y". Decidir sob pressão produz hesitação.
• Quem decide? Uma pessoa, nomeada, presente na janela.
• Replicação reversa é possível? Configurar a replicação do destino de volta para a origem antes do corte mantém a origem atualizada e estende a janela de rollback seguro. Vale o esforço em migrações críticas.

O ensaio

O item que mais reduz risco e o mais pulado por pressão de prazo.

Faça a migração inteira em homologação, com uma cópia de volume realista. Cronometre cada etapa. Execute o roteiro de corte com o mesmo texto que será usado na noite real. Quebre algo de propósito e exercite o plano de volta.

O ensaio revela três coisas que ninguém antecipa: o tempo real de cada etapa, os dois ou três passos que faltavam no roteiro, e a integração esquecida que ninguém tinha inventariado.

Depois do corte

• Monitoramento reforçado por alguns dias: latência de consulta, taxa de erro, conexões, espaço.
• Comparar o desempenho com a linha de base anterior. Servidor novo costuma precisar de ajuste de parâmetros e de estatística atualizada.
• Atualizar a estatística do banco no destino. Sem isso, o planejador toma decisões ruins e a aplicação parece mais lenta que antes.
• Acompanhar conexões no servidor antigo — é como você descobre o relatório que ninguém tinha mapeado.
• Só desligar a origem depois do prazo combinado, com backup final guardado.

Erros comuns

• Migrar sem backup feito especificamente para a migração.
• Não inventariar tudo que aponta para o banco.
• Esquecer usuários, permissões e parâmetros do servidor.
• Não ajustar as sequências e quebrar na primeira inserção.
• Alterar esquema durante a janela de replicação.
• Não reduzir o tempo de vida do DNS com antecedência.
• Permitir escrita nos dois lados.
• Não confirmar que o atraso de replicação chegou a zero.
• Nenhum critério de abortar definido antes.
• Ninguém nomeado para decidir.
• Pular o ensaio por falta de tempo.
• Desligar a origem no dia seguinte.
• Esquecer de atualizar a estatística no destino e culpar o servidor novo.

Onde a Solvefy/Cloud entra

Conduzimos migrações de banco com o roteiro completo: inventário de dependências levantado por observação real, replicação lógica configurada e monitorada, validação por contagem e soma de verificação, ensaio cronometrado em homologação, roteiro de corte minuto a minuto com responsáveis, critérios de abortar escritos, replicação reversa quando o risco justifica e acompanhamento no pós-corte. PostgreSQL, MariaDB e MongoDB — entre servidores, entre versões e entre provedores.

Precisa mover seu banco sem parar a operação? Diagnóstico gratuito, sem compromisso, em solvefy.cloud.

Solvefy/Cloud — Infraestrutura que cresce com você.