18.6. Atualizando um cluster PostgreSQL
Esta seção discute como atualizar os dados do banco de dados de uma distribuição PostgreSQL para uma distribuição mais recente.
O número da versão atual do PostgreSQL consiste em um número de versão principal e um número de versão secundária. Por exemplo, no número da versão 10.1, 10 é o número da versão principal e 1 é o número da versão secundária, o que significa que esta será a primeira versão secundária da versão principal 10. Para versões anteriores ao PostgreSQL versão 10.0, o número da versão consiste em três números, como 9.5.3. Nestes 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, o que significa que esta será a terceira versão secundária da versão principal 9.5.
Versões secundárias nunca mudam o formato de armazenamento interno e são sempre compatíveis com versões anteriores e posteriores com versões secundárias no 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, você simplesmente precisa substituir o arquivo executável quando o servidor for desligado e reiniciá-lo. O diretório de dados permanece o mesmo - pequenas atualizações são tão simples quanto isso.
Para a versão principal do PostgreSQL, o formato de armazenamento de dados interno é frequentemente alterado, o que complica a atualização. O método tradicional de mover dados para uma nova versão principal é despejá-los e recarregá-los no banco de dados, mas isso pode ser lento. Uma maneira mais rápida é pg_upgrade. Conforme discutido abaixo, o método de replicação também pode ser usado para atualizações.
A nova versão principal também costuma apresentar alguma incompatibilidade visível ao usuário, portanto, pode exigir alterações na programação do aplicativo. Todas as alterações visíveis ao usuário estão listadas nas notas de lançamento (Apêndice E), preste atenção especial à seção marcada "Migração". Se você estiver atualizando em várias versões principais, certifique-se de ler as notas de lançamento de cada versão intermediária.
Usuários cuidadosos vão querer testar seu aplicativo cliente na nova versão antes de mudar completamente. Portanto, geralmente é uma boa ideia criar uma instalação coexistente das versões antiga e nova. Ao testar uma atualização principal do PostgreSQL, considere as seguintes categorias de alterações possíveis:
Gerenciamento
As funções de administradores para monitorar e controlar o servidor são frequentemente alteradas e adicionadas em cada versão principal.
O SQL
geralmente inclui novas funções de comando SQL e nenhuma mudança no comportamento, a menos que especificamente mencionado nas notas de lançamento.
A API da biblioteca
geralmente adiciona novas funções às bibliotecas, como libpq, a menos que seja especificamente mencionado nas notas de lançamento.
Catálogo do
sistema As alterações no catálogo do sistema geralmente afetam apenas as ferramentas de gerenciamento de banco de dados.
API da linguagem C do servidor
Envolve mudanças na API da função back-end, que é escrita na linguagem de programação C. Essas alterações afetam o código que faz referência às funções internas de back-end do servidor.
18.6.1. Atualizando dados via pg_dumpall
Um método de atualização é despejar dados de uma versão principal do PostgreSQL e recarregá-los em outra versão principal - para fazer isso, você deve usar uma ferramenta de backup lógica, como pg_dumpall, o método de backup no nível do sistema de arquivos não Útil (isso também evita que você use um diretório de dados com uma versão incompatível do PostgreSQL, então tentar iniciar uma versão de servidor errada em um diretório de dados não causará muito dano).
Recomendamos que você use os programas pg_dump e pg_dumpall das versões mais recentes do PostgreSQL, para que você possa aproveitar as possíveis melhorias nestes programas. O programa de despejo lançado atualmente pode ler os dados em qualquer servidor com a versão 7.0 e superior.
Estas instruções assumem que sua instalação existente está no diretório / usr / local / pgsql e a área de dados está lá /usr/local/pgsql/data. Por favor, substitua seu caminho apropriadamente.
- Se você estiver criando um backup, certifique-se de que seu banco de dados não esteja sendo atualizado. Isso não afetará a integridade do backup, mas é claro que essas alterações não serão incluídas no backup. Se necessário, edite
/usr/local/pgsql/data/pg_hba.confas permissões no arquivo (ou um método equivalente) para não permitir que ninguém além de você use o banco de dados. Consulte o Capítulo 20 para obter informações adicionais sobre controle de acesso.
Para fazer backup da instalação do seu banco de dados, digite:
pg_dumpall > outputfile
Para fazer um backup, você pode usar o comando pg_dumpall da versão que está executando, consulte a Seção 25.1.2 para obter detalhes. No entanto, para obter os melhores resultados, tente usar o comando pg_dumpall do PostgreSQL 11.2, porque esta versão contém correções de bugs e melhorias para a versão anterior. Embora esta sugestão possa parecer estranha porque você ainda não instalou a nova versão, é aconselhável seguir esta sugestão se você planeja instalar a nova versão em paralelo. Nesse caso, você pode concluir a instalação normalmente e transferir os dados posteriormente. Isso também reduzirá o tempo de inatividade.
- Desligue o servidor antigo:
pg_ctl stop
Em sistemas que iniciam o PostgreSQL automaticamente, pode haver um arquivo de inicialização que fará a mesma coisa. Por exemplo, em um sistema Red Hat Linux, descobriremos que isso também funciona: /etc/rc.d/init.d/postgresql stopconsulte o Capítulo 18 para obter detalhes sobre como iniciar e parar o servidor.
- Se estiver restaurando de um backup, renomeie ou exclua o diretório de instalação antigo (se não for para uma versão específica). É uma boa ideia renomear o diretório, não excluí-lo, porque se você tiver um problema e precisar retornar a ele, ele ainda existirá. Lembre-se de que esse diretório pode consumir um espaço em disco considerável. Para renomear o diretório, use um comando semelhante:
mv /usr/local/pgsql /usr/local/pgsql.old(observe que o diretório é movido como uma unidade única para que o caminho relativo possa permanecer inalterado). - Instale a nova versão do PostgreSQL na Seção 16.4
- Se necessário, crie um novo cluster de banco de dados. Lembre-se de que você deve executar esses comandos ao fazer login em uma conta de usuário de banco de dados especial (se estiver atualizando, você já tem essa conta).
/usr/local/pgsql/bin/initdb -D /usr/local/pgsql/data - Restaure seu pg_hba.conf anterior e quaisquer modificações postgresql.conf.
- Para iniciar o servidor de banco de dados, use também uma conta de usuário de banco de dados especial:
/usr/local/pgsql/bin/postgres -D /usr/local/pgsql/data - Finalmente, use o novo psql para restaurar seus dados do backup:
/usr/local/pgsql/bin/psql -d postgres -f outputfileinstale o novo servidor em um diretório diferente e execute os servidores antigo e novo em portas diferentes em paralelo para obter o menor tempo de inatividade. Então você pode usá-lo assim:pg_dumpall -p 5432 | psql -d postgres -p 5433para transferir seus dados.
18.6.2. Atualizando dados via pg_upgrade
O módulo pg_upgrade permite que uma instalação seja atualizada "no local" de uma versão principal do PostgreSQL para outra versão principal. A atualização pode ser realizada em alguns minutos, especialmente ao usar o modo –link. Requer etapas semelhantes ao pg_dumpall acima, como iniciar / parar o servidor e executar o initdb. A documentação do pg_upgrade descreve as etapas necessárias.
18.6.3. Atualizar dados copiando
Você também pode usar a versão atualizada da replicação lógica do PostgreSQL para criar um servidor de backup. A replicação lógica oferece suporte à replicação entre as diferentes versões principais do PostgreSQL. O servidor de backup pode estar no mesmo computador ou em um computador diferente.
Depois de sincronizado com o servidor principal (executando a versão antiga do PostgreSQL), você pode alternar o host e usar o servidor de backup como host e, em seguida, desligar a instância do banco de dados antigo. Essa mudança torna o tempo de inatividade de uma atualização de apenas alguns segundos. Este método de atualização pode usar ferramentas de replicação lógica integradas e sistemas de replicação lógica externos, como pglogical, Slony, Londiste e Bucardo.