Atualização da versão secundária do Postgres

Basta fazer um dist-upgradeou algo parecido no Linux ou instalar as versões mais recentes no Windows/OSX. Versões secundárias garantem total compatibilidade com o diretório de dados (heap e índice).

É lógico, porém, que você terá que parar o banco de dados durante a atualização.

Dos documentos oficiais sobre versionamento

As versões secundárias são numeradas aumentando a última parte do número da versão. A partir da versão 10, esta é a segunda parte do número da versão, por exemplo, 10.0 a 10.1; para versões mais antigas, esta é a terceira parte do número da versão, por exemplo, 9.5.3 a 9.5.4. A equipe do PostgreSQL apenas adiciona correções de bugs a versões menores. Todos os usuários devem atualizar para a versão secundária mais recente o mais rápido possível. Embora as atualizações sempre apresentem algum risco, as versões secundárias do PostgreSQL corrigem apenas erros de segurança e corrupção de dados encontrados com frequência para reduzir o risco de atualização. A comunidade considera que não atualizar é mais arriscado do que atualizar.

Então, essencialmente, o PostgreSQL é tão conservador que as atualizações de número de versão secundária só são emitidas quando há mais risco de não atualizar do que atualizar. Trabalho com PostgreSQL há cerca de 15 anos. Não faço backups adicionais nem tomo precauções especiais ao fazer pequenas atualizações. Não estou dizendo que você não pode - até os médicos dizem que eles vêm com "algum risco".

Resumindo, uma pequena atualização de uma instalação do Postgres (também chamada de cluster) é bastante simples:

• parar o aglomerado
• substitua os binários do Postgres pela nova versão (os detalhes podem diferir aqui, dependendo do sistema operacional e do sabor)
• reinicie o cluster

Para um sistema de produção e um DBA que tenta ser mais cuidadoso, há mais duas coisas:

• um backup pode ser feito antes da atualização.

• ler as notas de lançamento é uma obrigação antes de executar a atualização.

  Às vezes, há casos em que mesmo uma pequena atualização requer etapas extras. Às vezes está reconstruindo alguns índices, às vezes coisas mais estranhas, etc. Na maioria das vezes, você não precisa fazer nada extra, mas ler essas notas é essencial, pois quando algum trabalho extra é necessário, é para evitar que algum bug não sendo corrigido ou para inverter alguma corrupção, etc.

  Se você deseja atualizar (exemplo) de 9.5.4 para 9.5.9, você também precisa ler todas as notas de versão intermediárias (9.5.5, 9.5.6, 9.5.7, 9.5.8, 9.5.9). Para as notas 9.5.5 específicas, veja abaixo.

Então os passos seriam:

• lendo as notas de lançamento e alterando o procedimento de acordo
• interrompa todas as conexões e impeça novas
• faça um backup (de todo o cluster com pg_basebackupou de cada banco de dados com pg_dump)
• parar o aglomerado
• substitua os binários do Postgres pela nova versão
• reinicie o cluster

Se houver replicação envolvida, você terá que considerar isso também:

Para um sistema de produção e um DBA que tenta ser mais cuidadoso, um backup pode ser feito antes da atualização:

• interrompa todas as conexões e impeça novas
• espere que todas as réplicas se atualizem
  e façam backup
• parar todos os clusters (mestre e réplicas)
• substitua os binários do Postgres pela nova versão (em cada cluster)
• reinicie todos os clusters

Uma variação neste caso é que o backup pode ser ignorado, se mantivermos uma ou mais réplicas paradas e com os binários antigos. Se por algum motivo precisarmos voltar para a versão secundária antiga, podemos promover essa réplica para master.

Para a versão 9.5.5 específica, por exemplo, as notas da versão dizem:

E.5. Liberação 9.5.5

Data de lançamento: 27/10/2016

Esta versão contém uma variedade de correções de 9.5.4. Para obter informações sobre novos recursos na versão principal 9.5, consulte a Seção E.10.

E.5.1. Migração para a Versão 9.5.5

Um dump/restauração não é necessário para aqueles que executam o 9.5.X.

No entanto, se sua instalação foi afetada pelo bug descrito na primeira entrada do log de alterações abaixo , após a atualização , talvez seja necessário tomar medidas para reparar mapas de espaço livre corrompidos.

Além disso, se você estiver atualizando de uma versão anterior à 9.5.2 , consulte a Seção E.8.

Então, precisamos ler este primeiro changelog também:

E.5.2. Mudanças

Corrigir o registro WAL de truncamento de mapas de espaço livre de relação e mapas de visibilidade (Pavan Deolasee, Heikki Linnakangas)

Era possível que esses arquivos não fossem restaurados corretamente durante a recuperação de falhas ou fossem gravados incorretamente em um servidor em espera. Entradas falsas em um mapa de espaço livre podem levar a tentativas de acessar páginas que foram truncadas fora da própria relação, normalmente produzindo erros como"could not read block XXX: read only 0 of 8192 bytes" . Falhas de soma de verificação no mapa de visibilidade também são possíveis, se a soma de verificação estiver habilitada.

Os procedimentos para determinar se há um problema e repará-lo, se houver, são discutidos em https://wiki.postgresql.org/wiki/Free_Space_Map_Problems .

Portanto, dump/restore não é necessário para passar de 9.5.4 para 9.5.5 e você só precisa verificar esse problema específico. Verifique seus logs de erros e pronto ;)

yum update  postgresql-version