Pular para conteúdo

Migração de Banco de Dados

Migrar banco de dados assusta porque a versão ingênua da migração é ruim: parar a aplicação, exportar tudo, importar tudo, torcer. Em uma base de 500 GB isso é uma madrugada inteira de indisponibilidade e nenhum caminho de volta.

A migração que a InteSys executa é outra: o banco novo é preenchido e mantido em sincronia enquanto o antigo continua atendendo produção. A parada real acontece só no momento de virar o endereço, e dura segundos.

Migração com carga inicial, replicação de mudanças, cutover e fluxo reverso armado para rollback

O fluxo reverso continua armado depois do cutover: é o que torna o rollback possível.

De onde os clientes costumam vir

Origem Complicação típica
Servidor próprio / colocation Versão antiga, sem réplica e com backup nunca testado
Provedor estrangeiro Latência ruim para usuário brasileiro e transferência internacional de dados pessoais
Banco gerenciado de nuvem pública Custo crescente, pouco controle de parâmetro e egresso caro na saída
VM de aplicação Banco convivendo com a aplicação no mesmo host, disputando CPU e I/O

Sair de provedor estrangeiro tem, além do ganho de latência, efeito de conformidade: o dado passa a ficar sob soberania brasileira, sem transferência internacional a documentar.

1. Levantamento

Antes de mover um byte:

  • Inventário — bancos, esquemas, tamanho por tabela, engines de armazenamento, extensões e character sets.
  • Versões — versão de origem e de destino. Salto de versão maior é migração e atualização: são dois riscos, e às vezes vale separá-los.
  • Dependências escondidas — triggers, stored procedures, jobs de cron, usuários com privilégio especial, replicação já existente.
  • Perfil de carga — pico de escrita e maiores consultas, para dimensionar o destino.
  • Requisito de janela — quanto de indisponibilidade o negócio tolera. É esse número que decide o método.

2. Escolha do método

Método Downtime Quando usar
Dump e restore Horas, proporcional ao tamanho Bases pequenas ou ambientes que podem parar de madrugada
Backup físico + replicação Minutos Mesma versão maior e mesmo engine; a réplica sobe do backup e alcança o primário
Replicação lógica / CDC Segundos Padrão para produção crítica; tolera troca de versão e ajuste de esquema
Blue/green de aplicação Zero percebido Quando a aplicação sabe escrever nos dois lados durante a transição

Na prática, quase toda migração de produção usa replicação lógica ou CDC: pg_logical/logical replication no PostgreSQL, replicação por binlog com GTID no MySQL, ou uma ferramenta de captura de mudanças quando origem e destino são heterogêneos.

3. Carga inicial

O destino é preenchido com uma cópia consistente da origem, marcada com a posição exata do log de transação (GTID no MySQL, LSN no PostgreSQL). Essa marca é o que permite retomar a replicação sem lacuna e sem duplicidade.

Durante a carga inicial, o banco de origem continua atendendo produção normalmente.

Índices depois dos dados

Em bases grandes, carregar dados com os índices já criados é várias vezes mais lento. A ordem é: esquema sem índices secundários → dados → índices → constraints → estatísticas.

4. Sincronização contínua

Terminada a carga, o destino passa a consumir o fluxo de mudanças da origem e o lag cai para segundos. Esse estado pode durar horas ou dias — e é exatamente o que dá liberdade para escolher o horário do cutover.

Nessa janela fazemos a validação a frio:

  • contagem de linhas por tabela nos dois lados;
  • checksum de amostras das tabelas críticas;
  • comparação de sequências, auto_increment e objetos de esquema;
  • execução das consultas mais pesadas da aplicação contra o destino, comparando plano de execução e tempo.

5. Cutover

O único momento de parada. Procedimento típico, de dois a cinco minutos no total e segundos de indisponibilidade real:

  1. Congelar escrita — a aplicação entra em modo somente leitura ou o pool é pausado.
  2. Drenar o lag — esperar o destino atingir lag zero. É a etapa que define a duração.
  3. Conferir — última comparação de contagem nas tabelas de maior escrita.
  4. Virar o endereço — DNS, connection string ou, preferencialmente, o proxy (ProxySQL, PgBouncer) passa a apontar para o novo cluster.
  5. Liberar escrita — a aplicação volta ao normal, já no banco novo.
  6. Armar o retorno — a replicação inversa (destino → origem) é ligada.

Rollback tem prazo de validade

O caminho de volta só existe enquanto a replicação inversa estiver ativa e a origem, intacta. Fixamos com o cliente uma janela de rollback — normalmente de 24 a 72 horas — e só depois dela a origem é desligada.

6. Estabilização

Nas primeiras horas e dias após o cutover:

  • monitoramento reforçado de latência, erros de conexão e consultas lentas;
  • comparação de desempenho com a linha de base coletada antes da migração;
  • ajuste de parâmetros com carga real, não sintética;
  • primeiro backup completo no destino, com restauração testada;
  • primeiro teste de failover já no ambiente novo.

Riscos conhecidos e como tratamos

Risco Tratamento
Diferença de collation entre origem e destino Comparada no levantamento; ordenação e chaves são conferidas antes do cutover
Sequência / AUTO_INCREMENT desalinhada Reposicionada no cutover, antes de liberar escrita
Tabela sem chave primária Bloqueia CDC em várias ferramentas; tratada no levantamento, não na virada
Objeto não replicado (trigger, job, usuário) Migrado explicitamente por checklist, não pelo fluxo de dados
Aplicação com endereço fixo no código Identificada antes; o proxy remove a dependência

Páginas Relacionadas