postgres postgresql upgrade

Upgrade

A estrutura interna dos arquivos do cluster/instância do PostgreSQL pode mudar entre versões majoritárias. Por essa razão, é necessário executar um passo de upgrade quando migrando de uma versão majoritária para outra mais recente.

Existem três estratégias diferentes para esse passo; qualquer uma delas é suficiente para realizar o upgrade com sucesso, inclusive saltando diversas versões majoritárias em uma única execução; e cada uma tem vantagens e custos que precisam ser avaliados para cada caso.

Importante! Antes de iniciar qualquer upgrade majoritário, é vital conferir os dois pontos a seguir:

  1. Garanta que está usando a versão minoritária mais recente possível para o PostgreSQL de origem e de destino.
  2. Garanta que existe ao menos um backup feito e testado recentemente, incluindo os segmentos de WAL necessários para a restauração.

pg_dump e pg_dumpall

A primeira estratégia é através dos utilitários pg_dump e pg_dumpall. Ela consiste em criar um novo cluster/instância de PostgreSQL na versão nova, seguido da exportação dos dados do banco original, e então a importação deles no banco novo.

As vantagens dessa estratégia são:

As desvantagens dela são:

É necessário se atentar para as versões dos PostgreSQL de origem, do pg_dump (e pg_dumpall), do pg_restore (ou psql) e do PostgreSQL de destino. Seguindo essa mesma ordem, as versões deles devem ser não decrescentes:

PostgreSQL (origem) <= pg_dump <= pg_restore <= PostgreSQL (destino)

Ou seja, essa sequência de versões está correta:

14 (origem) <= 14 <= 16 <= 16 (destino)

Mas essa sequência causará problemas:

14 (origem) <= 16 <= 16 !!! 14 (destino)

pg_upgrade

A segunda estratégia é através do utilitário pg_upgrade. Com ele, é possível converter o próprio diretório de dados (e de tablespaces) do cluster/instância para a nova versão. Como essa é uma operação sobre os dados em disco, o tempo de upgrade vai ser proporcional ao espaço ocupado em disco e inversamente proporcional à velocidade de leitura e escrita dos discos abaixo do diretórios de dados e de tablespaces.

Adicionalmente, também existe um modo de link, em que, ao detectar que um objeto não teve mudança estrutural entre as duas versões majoritárias, o objeto não precisa ser duplicado em disco, mas pode ser ligado por um hard link. Isso evita a duplicação do espaço em disco e agiliza o procedimento, mas inviabiliza um rollback caso seja necessário.

As vantagens dessa estratégia são:

As desvantagens dela são:

Replicação Lógica

A terceira estratégia é através de replicação lógica, disponível no PostgreSQL a partir da versão 10. Com ela, os clusters/instâncias de origem e de destino mantêm uma replicação ativa de um para o outro até o momento do chaveamento da aplicação. Dessa forma, a indisponibilidade é minimizada.

As vantagens dessa estratégia são:

As desvantagens dela são: