5 respostas

Não faça um pg_dump simples e restore em um banco de dados vazio se não quiser ficar com horas de downtime - em vez disso use pg_upgrade que roda no mesmo servidor sem necessidade de exportar/importar, ou se quiser migrar para outro servidor use replicação lógica para manter a app rodando enquanto se sincroniza. Com 50GB você vai economizar um monte de tempo e estresse fazendo desse jeito.

Sua aplicação consegue ficar um tempo sem escrever no banco de dados ou você precisa de zero downtime absoluto? Se conseguir parar as escritas nem que seja por 5-10 minutos, pg_upgrade é sua melhor amiga porque converte os arquivos no mesmo disco sem exportar nada, então com 50GB você economiza horas. Agora, se precisa evitar downtime completamente, tem um truque que poucas vezes mencionam: você consegue usar replicação lógica (logical replication) para sincronizar o banco antigo com o novo em paralelo enquanto continua rodando, e depois você muda quando tudo estiver atualizado - é um pouco mais complicado de configurar mas é ouro se não conseguir parar o serviço. Dito isso, antes de qualquer coisa teste em um ambiente de staging nem que seja com um dump de alguns GB para ver quanto tempo leva no seu setup específico.

DiegoHernandez asker Dá pra gente parar de escrever por 10 minutos tranquilamente. Vou testar o pg_upgrade então, vlw pela dica.

Você já verificou se sua versão 12 é compatível diretamente com a 15, ou precisa passar por versões intermediárias? O que ninguém menciona é que além do pg_upgrade, você deveria considerar fazer um backup completo antes de qualquer coisa, porque embora pg_upgrade seja bem confiável, ter esse respaldo te dá tranquilidade - especialmente com 50GB. Se de jeito nenhum você precisa evitar downtime total, existe replicação lógica (logical replication) onde você configura uma instância secundária com a versão 15, a sincroniza em paralelo e depois faz failover quando estiver pronta, mas isso é mais complexo. A maioria das pessoas que conheço acaba escolhendo pg_upgrade com uma janela de manutenção curta porque é o mais prático e rápido para um volume assim.

Com 50GB você precisa ter cuidado, mas pg_upgrade é sim a opção correta se conseguir tolerar aquele downtime de 5-10 minutos. O que a maioria não menciona é que PostgreSQL 12 para 15 é um salto que pg_upgrade lida sem problemas em uma única passada, então não precisa de versões intermediárias. Meu conselho: antes de qualquer coisa, faz um backup completo com pg_basebackup ou pg_dump em paralelo (usa pg_dump com a opção -j para paralelizar, reduz bastante o tempo), e aí sim executa pg_upgrade no seu servidor de produção durante uma janela de manutenção. Mas depois do upgrade roda ANALYZE nas tabelas grandes porque mudam umas estatísticas internas e você pode acabar com queries lentas se não fizer isso.

Olha, se você conseguir tolerar pelo menos 10-15 minutos de downtime, pg_upgrade é definitivamente o seu caminho porque faz a migração no mesmo servidor sem exportar/importar todos os dados (com 50GB isso te economiza muito tempo). O que ninguém mencionou aqui é que antes de qualquer coisa, você precisa verificar se há extensões instaladas que não sejam compatíveis entre versões, porque isso pode travar todo o processo na última hora e deixar você com surpresas desagradáveis quando já estiver na conversão. Minha recomendação: faça um backup completo com pg_basebackup mesmo assim (por segurança), teste tudo em um servidor de staging primeiro, e depois sim lance o pg_upgrade em produção.

Sua resposta

Entrarpara responder.