postgres postgresql 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.

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:

• a simplicidade dos comandos;
• é possível mover partes do cluster/instância escolhendo quais bancos de dados exportar e importar;
• é possível usar máquinas diferentes para cada versão.

As desvantagens dela são:

• alto tempo de importação, já que os dados são exportados logicamente e então os objetos (tabelas, índices, visões materializadas...) são recriados no no destino durante a importação;
• dobra o espaço em disco ocupado durante a execução, já que um cluster novo precisa existir com uma cópia dos dados;
• o ambiente deve ficar indisponível durante o upgrade, caso contrário é possível que a aplicação execute transações no banco de origem depois do início do upgrade, então elas não existirão no snapshot visto pelo dump e, quando o chaveamento foi feito, elas não serão vistas no banco de destino.

É 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)

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:

• mais rápido que a estratégia de dump para clusters/instâncias grandes;
• no modo de link, é muito mais rápido que as outras estratégias e não ocupa o dobro do espaço em disco;
• permite upgrade de clusters de alta disponibilidade com tempo mínimo de parada das réplicas.

As desvantagens dela são:

• necessário usar apenas uma máquina que contenha os binários das duas versões;
• necessário que a máquina tenha espaço para os dois diretórios de dados (exceto em modo de link);
• no modo de link, os diretórios precisam estar em um mesmo sistema de arquivos;
• no modo de link, o diretório original se torna inutilizável após o primeiro início da versão nova, já que ela pode alterar arquivos que ambos compartilham;
• o ambiente deve ficar indisponível durante o upgrade;
• não é possível converter bancos de dados específicos pois a operação é sobre o cluster/instância inteiro.

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:

• tempo de indisponibilidade é mínimo, dependendo apenas do chaveamento da aplicação, que pode ser feito também por reapontamento de um proxy;
• é possível migrar bancos de dados independentes uns dos outros;
• é possível usar máquinas diferentes para cada versão.

As desvantagens dela são:

• dobra o espaço em disco ocupado durante a execução, já que um cluster novo precisa existir com uma cópia dos dados;
• a replicação lógica gera um volume muito maior de WAL que o normal;
• a replicação lógica atualmente não replica DDL, então passos adicionais precisam ser tomados;
• é necessário que o PostgreSQL de origem esteja na versão 10 ou mais recente.