PostgreSQL major upgrade no Percona Operator sem dump, restore ou perda de dados

O gargalo que esse recurso resolve

Até a chegada desse recurso, subir um cluster do Percona Operator for PostgreSQL↳PostgreSQL11 conteúdosPostgreSQL via SSL com GolangData · abr 20195 itens legais sobre data types do PostgreSQLData · mar 20195 serviços gratuitos na cloud para bancos de dados PostgresData · fev 2025Ver tudo em Data → de uma versão major para outra (de PostgreSQL 16 para 17, por exemplo) era um problema sem solução elegante dentro do Kubernetes↳Kubernetes18 conteúdosGerenciamento de infraestrutura multicloud com Kubernetes proporciona otimização e economiaDevSecOps · set 2021Azure Kubernetes Services – AKS: referências gratuitas e dicas para solução de problemas comunsDevSecOps · abr 2019Kubernetes em produção: o que ninguém te conta e você aprende tarde demaisDev (Back & Front) · abr 2026Ver tudo em DevSecOps →. Segundo a Percona, só havia duas saídas práticas: dump/restore manual para um cluster novo, ou replicação lógica. Rodar pg_upgrade manualmente, direto no volume do pod, nunca foi um caminho suportado pelo operator.

Nenhuma dessas alternativas é trivial em produção. Provisionar um cluster paralelo e migrar os dados manualmente é operação cara e sujeita a erro humano. Replicação lógica tem limitações conhecidas: nem tudo replica de forma transparente, e é preciso reconciliar o setup depois. Mexer na camada de storage por fora do controlador do operator é a receita clássica para deixar o cluster em estado inconsistente.

A Percona endereçou essa lacuna com um recurso de major upgrade lançado como technical release no operator v2.4.0 e promovido a disponibilidade geral (GA) no operator v2.9.0, depois de passar por algumas releases de maturação, segundo o post oficial da engenharia (Anil Joshi, 9 de novembro de 2026).

Como funciona por baixo do capô

O mecanismo não é mágica: é pg_upgrade rodando em modo in-place, orquestrado pelo operator via um recurso customizado chamado PerconaPGUpgrade. O fluxo documentado segue uma sequência fixa:

1. Você cria um recurso PerconaPGUpgrade apontando para o cluster e a versão de destino.
2. O operator pausa o cluster e desliga os pods.
3. Um Job de upgrade roda pg_upgrade --link no volume da instância primária, criando um novo diretório de dados (por exemplo pg17) ao lado do antigo (pg16).
4. As réplicas são ressincronizadas a partir da primária já atualizada.
5. O cluster reinicia na nova versão major.

Aqui vai o ponto que, como DBA, eu não deixaria passar batido: isso não é zero-downtime. O cluster é pausado e desligado durante o processo. O ganho real dessa feature é não precisar de dump/restore nem de replicação lógica, com uma janela de manutenção mais curta e previsível, não a ausência de janela.

Os três riscos que o post da Percona lista

A engenharia da Percona é direta sobre o que precisa de atenção antes de disparar o upgrade:

• Mudança de SO e glibc: a partir do operator v2.6.0, a imagem base trocou de UBI8 para UBI9, o que muda a versão do glibc de 2.28 para 2.34. Isso afeta diretamente a collation usada pelos índices.
• Extensões não são upgradadas automaticamente: a pgaudit, por exemplo, precisa ser removida (DROP EXTENSION) e recriada em cada banco onde estiver instalada.
• Réplicas lógicas são invalidadas: o major upgrade remove as réplicas lógicas existentes. Depois do upgrade, é preciso verificar e ressemear cada uma delas manualmente.

Mesmo se a versão major e minor do sistema operacional forem iguais, a versão de patch pode mudar o glibc por baixo. Isso também exige verificar a collation e, no mínimo, reconstruir os índices.

Anil Joshi, PerconaWe should always compare the complete patch version, as it might happen that we have the same Major/Minor version, say RHEL(8.x); however, the Patched version (8.x.x) is different and ultimately affects the underlying glibc.

Diagnosticando o ambiente antes de mexer em qualquer coisa

Antes de qualquer upgrade, o primeiro passo é levantar o estado real do cluster: versão do operator, versão do Postgres, SO e glibc da imagem em uso. É o mesmo raciocínio de qualquer migração de banco bem feita: não se mexe sem saber exatamente de onde se está partindo.

kubectl get pods -n postgres-operator

No ambiente de referência do post, a saída mostra o cluster rodando com três instâncias, pgBouncer e o operator ativos. Dentro de um dos pods, dá para confirmar SO e glibc diretamente:

cat /etc/os-release
getconf GNU_LIBC_VERSION
rpm -q glibc

No caso documentado, a saída aponta RHEL 8.10 com glibc-2.28-251.el8_10.2.x86_64, exatamente a versão que muda quando o operator passa a usar UBI9.

O caminho do upgrade: operator primeiro, incrementalmente

A imagem do PostgreSQL 17 só fica disponível a partir do operator v2.6.0. Só que não dá para pular direto de v2.4.0: o caminho suportado é incremental (2.4.0 → 2.5.1 → 2.6.0). Cada etapa aplica o CRD, o RBAC e faz o patch da imagem do deployment do operator.

kubectl apply --server-side -f https://raw.githubusercontent.com/percona/percona-postgresql-operator/v2.5.1/deploy/crd.yaml

kubectl apply --server-side -f https://raw.githubusercontent.com/percona/percona-postgresql-operator/v2.5.1/deploy/rbac.yaml -n postgres-operator

kubectl -n postgres-operator patch deployment percona-postgresql-operator \
  -p'{"spec":{"template":{"spec":{"containers":[{"name":"operator","image":"docker.io/percona/percona-postgresql-operator:2.5.1"}]}}}}'

Depois de confirmar o rollout com kubectl rollout status deployments percona-postgresql-operator -n postgres-operator, o mesmo trio de comandos se repete para a tag 2.6.0. O ponto importante aqui: atualizar o operator não toca no banco. Os pods do PostgreSQL continuam na mesma versão, com o mesmo SO e glibc, porque operator e cluster de dados têm ciclos de vida separados. Só depois de chegar em v2.6.0 a imagem do PostgreSQL 17 fica disponível para o PerconaPGUpgrade.

O que fazer na prática, como DBA

Com o operator já em v2.6.0 (ou, melhor ainda, direto na versão GA v2.9.0, recomendada pela própria Percona), o roteiro que eu seguiria antes de disparar o PerconaPGUpgrade é este:

1. Backup completo e testado do cluster: o upgrade in-place mexe no volume da primária, e sem backup validado não há plano B.
2. Levantamento de extensões instaladas em cada banco, cruzando com a lista das que não acompanham o upgrade automaticamente.
3. Inventário de toda réplica lógica ativa, já sabendo que ela será invalidada e vai precisar ser recriada do zero.
4. Validação de collation e, se necessário, reindexação após a troca de UBI8 para UBI9.
5. Janela de manutenção comunicada: o cluster pausa e reinicia, então downtime zero não é a promessa certa a fazer para quem depende desse banco.

A Percona também desaconselha um atalho tentador: usar imagens customizadas para manter UBI8 rodando com o operator v2.6.0 e o PostgreSQL 17. O post é claro que esse caminho não é recomendado e pode gerar falhas não testadas; a rota suportada é migrar o SO junto com o operator e tratar a collation como consequência esperada.

O que ainda fica em aberto

O post da Percona não detalha o tempo médio de pausa em bases grandes, nem como o pg_upgrade --link se comporta em volumes muito volumosos dentro de PVCs do Kubernetes. É um ponto que vale testar em homologação antes de levar para produção. Também não há, no material, orientação oficial sobre rollback caso o upgrade falhe no meio do caminho: o diretório antigo (pg16) fica ao lado do novo, mas o procedimento de reverter não está descrito. Quem for adotar o recurso deve testar esse cenário de falha isoladamente antes de confiar nele em ambiente crítico.

Fonte: Percona Database Blog