Esta seção discute como atualizar os dados dos bancos de dados de uma versão do PostgreSQL para uma versão mais recente.
Os números atuais de versão do PostgreSQL consistem no número da versão principal, e no número da versão secundária. Por exemplo, na versão número 10.1, 10 é o número da versão principal, e o 1 é o número da versão secundária, significando que esta seria a primeira versão secundária da versão principal 10. Para versões anteriores ao PostgreSQL versão 10.0, os números de versão consistem em três números, por exemplo, 9.5.3. Nesses casos, a versão principal consiste nos primeiros grupos de dois dígitos do número da versão, por exemplo, 9.5, e a versão secundária é o terceiro número, por exemplo, 3, significando que esta seria a terceira versão secundária da versão principal 9.5.
Versões secundárias nunca alteram o formato de armazenamento interno, sendo sempre compatíveis com versões secundárias anteriores e posteriores do mesmo número de versão principal. Por exemplo, a versão 10.1 é compatível com a versão 10.0 e a versão 10.6. Da mesma forma, por exemplo, 9.5.3 é compatível com 9.5.0, 9.5.1 e 9.5.6. Para atualizar entre versões compatíveis, basta substituir os executáveis enquanto o servidor estiver inativo e reiniciar o servidor. O diretório de dados permanece inalterado — atualizações menores são simples assim.
Para as versões principais do PostgreSQL, o formato de armazenamento de dados interno está sujeito a alterações, complicando as atualizações. O método tradicional para mover dados para uma nova versão principal é descarregar e recuperar (dump/restore) o banco de dados, embora isto possa ser lento. Um método mais rápido é usar o programa pg_upgrade. Os métodos de replicação também estão disponíveis, conforme discutido abaixo. (Se estiver sendo usada uma versão pré-empacotada do PostgreSQL, ela pode fornecer scripts para auxiliar as atualizações de versões principais. Consulte a documentação do pacote para obter detalhes.)
Novas versões principais também geralmente apresentam algumas incompatibilidades visíveis ao usuário, portanto, podem ser necessárias alterações na programação da aplicação. Todas as alterações visíveis ao usuário estão listadas nas notas da versão (veja Notas da versão); preste atenção especial à seção chamada “Migration”. Embora seja possível atualizar de uma versão principal para outra sem atualizar para versões intermediárias, devem ser lidas as notas de versão principal de todas as versões intermediárias.
Os usuários cautelosos vão querer testar suas aplicações clientes na nova versão antes de mudar completamente; portanto, geralmente é uma boa ideia configurar instalações simultâneas de versões antigas e novas. Ao testar uma atualização de versão principal do PostgreSQL, considere as seguintes categorias de possíveis alterações:
Os recursos disponíveis para os administradores monitorarem e controlarem o servidor geralmente mudam e melhoram em cada versão principal.
Normalmente, uma nova versão só inclui novos recursos de comando SQL, e não alterações no comportamento, a menos que esteja especificamente mencionado nas notas de lançamento da versão.
Normalmente, bibliotecas como libpq apenas adicionam novas funcionalidades, novamente, a menos que esteja mencionado nas notas de lançamento da versão.
As alterações do catálogo do sistema geralmente afetam apenas as ferramentas de gerenciamento de banco de dados.
Envolve alterações na API de funções de processo servidor, escrita na linguagem de programação C. Estas alterações afetam o código que faz referência às funções de processo servidor.
Um método de atualização é descarregar os dados de uma versão principal do PostgreSQL, e recuperá-los em outra (dump/restore) — para fazer isto, deve ser usada uma ferramenta de cópia de segurança lógica, como o pg_dumpall; os métodos de cópia de segurança no nível do sistema de arquivos não funcionam. (Existem verificações que impedem o uso de um diretório de dados com uma versão incompatível do PostgreSQL, portanto, nenhum grande dano pode ser causado ao tentar iniciar a versão errada do servidor em um diretório de dados.)
É recomendado que sejam usados os programas pg_dump e pg_dumpall da versão mais recente do PostgreSQL, para aproveitar as melhorias que possam ter sido feitas nesses programas. As versões correntes dos programas de dump podem ler dados de qualquer versão do servidor até a 9.2.
As instruções a seguir assumem que a instalação existente está no
diretório /usr/local/pgsql, e que a área de
dados está em /usr/local/pgsql/data.
Substitua os caminhos adequadamente.
Se estiver fazendo uma cópia de segurança, certifique-se de que o
banco de dados não está sendo atualizado.
Isto não afeta a integridade da cópia de segurança, mas é claro
que os dados alterados não serão incluídos.
Se for necessário, edite as permissões no arquivo
/usr/local/pgsql/data/pg_hba.conf
(ou equivalente) para impedir o acesso de todos, exceto você.
Veja Autenticação de cliente para obter
informações adicionais sobre controle de acesso.
Para fazer uma cópia de segurança da instalação do banco de dados, execute:
pg_dumpall > arquivo_de_saída
Para fazer a cópia de segurança, pode ser usado o comando pg_dumpall da versão que está sendo executada no momento; veja Using pg_dumpall para obter mais detalhes. No entanto, para obter melhores resultados tente usar o comando pg_dumpall do PostgreSQL 18.1, uma vez que esta versão contém correções de erros e melhorias em relação às versões mais antigas. Embora este conselho possa parecer sem sentido, já que a nova versão ainda não foi instalada, é recomendável segui-lo se for planejado instalar a nova versão em paralelo com a versão antiga. Neste caso, pode ser concluída a instalação normalmente, e transferido os dados posteriormente. Também diminui o tempo de servidor parado.
Parar o servidor antigo:
pg_ctl stop
Nos sistemas que têm o PostgreSQL ativado na inicialização, provavelmente existe um comando de controle que faça a mesma coisa. Por exemplo, em um sistema Red Hat Linux, pode-se descobrir que o seguinte comando funciona:
/etc/rc.d/init.d/postgresql stop
Veja Configuração e operação do servidor para obter detalhes sobre como iniciar e parar o servidor.
Se estiver recuperando a partir da cópia de segurança, renomeie ou exclua o diretório de instalação antigo, se não for específico da versão. É uma boa ideia renomear o diretório, em vez de excluí-lo, para o caso de acontecerem problemas e ser necessário retornar para ele. Lembre-se de que o diretório de instalação pode consumir um espaço em disco significativo. Para renomear o diretório, pode ser usado um comando como este:
mv /usr/local/pgsql /usr/local/pgsql.old
(Certifique-se de mover o diretório como uma única unidade, para que os caminhos relativos permaneçam inalterados.)
Instale a nova versão do PostgreSQL conforme descrito em Instalação a partir do código-fonte.
Crie um novo agrupamento de bancos de dados, se for necessário. Lembre-se de que estes comandos devem ser executados estando conectado à conta de usuário do banco de dados (a qual já existe se estiver atualizando).
/usr/local/pgsql/bin/initdb -D /usr/local/pgsql/data
Recupere o arquivo pg_hba.conf anterior, e
quaisquer modificações em postgresql.conf.
Inicie o servidor de banco de dados, usando novamente a conta de usuário do banco de dados:
/usr/local/pgsql/bin/postgres -D /usr/local/pgsql/data
Por fim, recupere os dados da cópia de segurança com
/usr/local/pgsql/bin/psql -d postgres -f arquivo_de_saída
usando o novo psql.
O menor tempo de inatividade pode ser obtido instalando o novo servidor em um diretório diferente, e executando os servidores antigo e novo em paralelo, em portas diferentes. Assim pode ser usado algo como
pg_dumpall -p 5432 | psql -d postgres -p 5433
para transferir os dados.
O módulo pg_upgrade permite que uma instalação
seja migrada in loco de uma versão
principal do PostgreSQL para outra.
As atualizações podem ser realizadas em minutos, principalmente
no modo --link.
Requer passos semelhantes ao pg_dumpall
acima, por exemplo, iniciar/parar o servidor, e executar o
initdb.
A documentação do
pg_upgrade descreve os passos necessários.
Também é possível usar métodos de replicação lógica para criar um servidor em modo de espera (standby) com a versão atualizada do PostgreSQL. Isto é possível, porque a replicação lógica oferece suporte a replicação entre versões principais diferentes do PostgreSQL. A servidor em modo de espera pode estar no mesmo computador, ou em um computador diferente. Após sincronizar com o servidor primário (executando a versão mais antiga do PostgreSQL), pode-se trocar os primários, tornando o que está em modo de espera em primário, e desligar a instância do servidor de banco de dados mais antiga. Esta alternância resulta em apenas alguns segundos de tempo de inatividade para uma atualização.
Este método de atualização pode ser executado usando os recursos de replicação lógica integrados, bem como usando sistemas externos de replicação lógica, como pglogical, Slony, Londiste e Bucardo.