Atualização de versão minor do PostgreSQL (patch)

Atualização minor dentro da mesma versão principal (ex.: 17.4 → 17.x): revisão das release notes, backup e preservação dos RPM/deb atuais para rollback. Em servidor único, com uma interrupção curta; em um cluster com streaming replication, primeiro os standbys e depois o primary via switchover (rolling); em um cluster Patroni, as replicas são atualizadas com patronictl restart e o leader após patronictl switchover. Inclui atualização de extensões, verificação e um runbook de rollback (downgrade). Ao final, todos os servidores rodam a mesma nova versão minor e você continua com os arquivos da versão anterior para rollback.

Se a versão principal muda (ex.: 16 → 17), use pg-major-upgrade em vez deste guia; a atualização do próprio software Patroni está em pg-patroni.

Topologia: 1 servidor, primary + standbys ou um cluster Patroni

Cenários

• Atualização minor — Migrar para uma versão minor mais nova dentro da mesma versão principal (ex.: 17.4 → 17.6): correções de segurança e de bugs. Interrupção curta em servidor único, rolling em cluster.
• Rollback: voltar à versão minor anterior (downgrade) — Um bug ou regressão apareceu na nova versão minor: faça o rollback com os RPM/deb salvos da versão anterior. O diretório de dados não muda.

Antes de começar

• O PostgreSQL … está instalado a partir do repositório PGDG e em execução (pg-install). A atualização é feita dentro da mesma versão principal; para … → outra versão principal, use o guia pg-major-upgrade.
• As release notes de cada versão minor entre a versão atual e a de destino foram lidas. Em especial, foi anotado se a seção "Migration to Version …" exige alguma ação adicional (REINDEX, mudança de parâmetro): https://www.postgresql.org/docs/release/
• Os servidores acessam o repositório PGDG ou um mirror interno, e o mirror está atualizado.
• A janela de manutenção foi aprovada… (o serviço fica parado de alguns segundos a alguns minutos)… (as conexões caem por alguns segundos no switchover/restart)…; a equipe da aplicação foi informada.
• O último backup foi bem-sucedido… (pgbackrest info status ok)… e é possível tirar snapshots de VM/disco dos servidores.
• Todos os standbys estão em streaming e sem atraso.
• Como os papéis mudam após o switchover, o pg_hba.conf de cada node permite conexões replication a partir dos outros nodes, e a senha de … está no arquivo ~/.pgpass do usuário postgres em todos os nodes.
• O cluster não é gerenciado por uma ferramenta de HA como Patroni ou repmgr. Se o Patroni o gerencia, escolha Patroni em Topologia; para repmgr, veja as Notas. Os passos de switchover manual deste caminho conflitam com as decisões da ferramenta de HA.
• O cluster Patroni está saudável: um Leader, todas as replicas em streaming, Lag pequeno e Maintenance mode desligado. … é o leader atual; os nomes das replicas correspondem aos nomes de membro do Patroni.
• Os comandos do patronictl que fazem alterações (restart, switchover) exigem autenticação na REST API; o usuário/senha está em /etc/patroni/patroni.env em todos os nodes (instalação do pg-patroni). Se você usa outra organização, restapi.authentication precisa estar definido no arquivo que o patronictl lê com -c.
• Antes da atualização, os arquivos RPM/deb da versão anterior foram salvos no diretório … e o número da versão anterior está em …/prev-version.txt. Sem esses arquivos, você precisa baixar a versão anterior do repositório (EL: o PGDG mantém versões antigas; Debian/Ubuntu: apt-archive.postgresql.org).

Fases do guia

• Verificações prévias — Registrar a versão atual · Listar as versões no repositório · Revisar as release notes · Listar as extensões instaladas · Verificar transações longas e prepared transactions
• Backup e ponto de retorno — Fazer backup (pgBackRest) · Fazer backup (pg_dumpall + snapshot) · Guardar os arquivos RPM/deb atuais
• Cluster Patroni: verificação prévia — Verificar o estado do cluster e os papéis
• Atualização — Executar um checkpoint · Parar o PostgreSQL · Atualizar o software · Iniciar o PostgreSQL
• Atualização do primary (interrupção curta) — Executar um checkpoint · Parar o primary · Atualizar o software · Iniciar o primary
• Switchover e atualização do antigo primary — Verificar se a replicação está em dia · Parar as escritas da aplicação · Parar o antigo primary de forma limpa e anotar o último checkpoint · …: verificar se todo o WAL chegou e promover · Redirecionar as aplicações para o novo primary · Criar um replication slot para o antigo primary …
• Leader: switchover e atualização do antigo leader — Antigo leader: atualizar o software · Switchover: tornar … o leader · Reiniciar o antigo leader (…) · Verificar o estado final do cluster
• Extensões e verificação — Atualizar as extensões (ALTER EXTENSION … UPDATE) · Atualizar as extensões (ALTER EXTENSION … UPDATE) · Aplicar as ações adicionais das release notes · Verificar a versão e o status · Procurar erros nos logs · Backup pós-atualização …
• Rollback (downgrade) — Verificar a versão anterior · …: parar, instalar a versão anterior, iniciar · …: instalar a versão anterior e reiniciar com o Patroni · Leader: instalar a versão anterior · Transferir o leader e reiniciar o antigo leader · …Parar o primary…Parar o PostgreSQL… …