Patch de SO sem downtime no PostgreSQL: por que a HA precisa cobrir a pilha inteira

Um banco de dados↳Banco de dados134 conteúdosSQL ou NoSQL: eis a questão!!Data · mar 2020Banco de dados: como organizar e dar segurança para milhões de dados de loteriasData · mai 20215 serviços gratuitos na cloud para bancos de dados PostgresData · fev 2025Ver tudo em Data → saiu do ar por causa de um patch de segurança, e o PostgreSQL nunca foi o objeto do patch. É com esse caso concreto que Umair Shahid abre seu artigo no Planet PostgreSQL, publicado pela Stormatics. O time precisava atualizar o kernel, o tipo de atualização que só surte efeito após reboot, e fez o que quase todo mundo faz na primeira vez: agendou janela de manutenção, derrubou o banco, aplicou o patch, reiniciou e voltou. Uma indisponibilidade planejada, limpa, para algo que não tinha nada a ver com o banco.

O ponto de Shahid é o que interessa para quem opera PostgreSQL em escala: disponibilidade não é propriedade do processo do banco, é propriedade de toda a pilha sobre a qual ele roda. E boa parte dos times constrói HA para sobreviver a uma queda do Postgres, mas nunca ao chão em que o Postgres está de pé.

O banco não se sustenta sozinho

O PostgreSQL roda sobre um sistema operacional, que roda sobre um kernel. Na maioria dos ambientes modernos isso significa ainda um runtime de contêiner, uma camada de storage, uma camada de rede e, embaixo de tudo, um hypervisor ou host físico. O Postgres fica no topo dessa pilha e confia em tudo o que está abaixo.

Cada camada afeta o uptime, e cada uma emite patches por conta própria:

• O kernel recebe uma correção de segurança que exige reboot.
• O glibc ganha uma atualização.
• O runtime de contêiner muda de versão.
• O driver de storage tem um CVE.

Nenhuma dessas coisas é um problema do Postgres, e todas elas podem derrubar o Postgres se a única falha contra a qual você se protegeu foi o processo do banco cair. Como resume Shahid, essa é a armadilha:

Os times constroem alta disponibilidade para sobreviver a um crash do banco, um nó morrendo, um disco enchendo. Aí uma atualização rotineira de glibc chega, alguém reinicia a máquina, e o banco vai junto. A indisponibilidade é arquivada como "manutenção planejada", todo mundo segue em frente, e ninguém percebe que o desenho de disponibilidade nunca cobriu o terreno em que o banco estava apoiado.

Umair Shahid, Stormatics

Por que a janela de manutenção vira o padrão

A janela de manutenção é um hábito fácil de adotar porque funciona, mais ou menos. Você anuncia, absorve o impacto, aplica o patch e a vida continua. O modelo só deixa de servir quando o negócio opera 24/7: uma plataforma de pagamentos não tem hora tranquila, um banco tem fechamento de lote que não pode atrasar, um SaaS com clientes em todos os fusos não tem 2h da manhã que seja 2h da manhã para todos.

Pior: em ambiente regulado, patch de SO não é opcional. Quando um CVE de kernel aparece, segurança e compliance querem a correção aplicada imediatamente, não na próxima janela. Formam-se então duas forças puxando em sentidos opostos: aplicar patch rápido para permanecer seguro e permanecer no ar para cumprir o SLA. O modelo de janela obriga a escolher. Um cluster construído para operação rolante elimina a escolha.

O patching rolante, um nó por vez

Em um cluster HA bem construído, patching de SO é uma operação rolante: você atualiza um nó por vez enquanto o banco fica no ar o tempo todo, e o Postgres em si nunca é tocado. O formato proposto por Shahid é direto:

1. Construa uma imagem nova de nó com o SO já corrigido. Mesma versão do Postgres, mesma configuração, tudo idêntico acima do SO. A única mudança é a camada que se está corrigindo.
2. Aplique primeiro nas réplicas. Pare o Patroni em uma réplica, suba o nó com a nova imagem e deixe-o reingressar no cluster e recuperar a replicação.
3. Com todas as réplicas corrigidas e saudáveis, dispare um switchover controlado. O papel de primário migra para um nó já corrigido.
4. Corrija o antigo primário do mesmo jeito. Ele volta como réplica, já sobre a nova imagem.

O que ninguém sente é uma indisponibilidade: a única interrupção percebida é um switchover medido em segundos, num momento que você escolhe. Compare com o reboot completo de um primário único, em que você fica fora pelo tempo que a máquina levar para voltar, num horário que o agendamento do patch escolheu por você.

Repare no que não aconteceu: o Postgres ficou intocado. Mesmos binários, mesma config, mesmos arquivos de dados. A operação inteira trocou o chão sob o banco. Isso não é upgrade de banco, é manutenção de infraestrutura que o banco atravessa limpo.

O que torna o patch rolante realmente seguro

Os quatro passos parecem fáceis no papel. O que os torna seguros em produção é a excelência operacional em volta deles, e é aí que aparece a diferença entre um cluster HA de verdade e um esperançoso. Shahid lista cinco condições:

• As conexões precisam seguir o switchover. Se as aplicações conectam num endereço fixo de primário, o switchover só muda o lugar da indisponibilidade em vez de removê-la. É preciso uma camada de roteamento na frente: um load balancer, um pooler como PgBouncer, ou um IP virtual que acompanhe o líder. Assim, quando o papel de primário migra, as novas conexões chegam no novo líder sem ninguém reconfigurar nada.
• A replicação precisa estar em dia antes do switch. Promover uma réplica atrasada é fazer switchover para um banco lento, ou pior. Cheque o lag de replicação antes de promover, e entenda se você roda replicação síncrona ou assíncrona, porque isso define quanto dado em trânsito um switchover pode custar.
• Health checks e quórum precisam ser honestos. O Patroni decide com base no que o cluster reporta sobre si mesmo. Se um nó volta com a nova imagem mas o health check está mentindo, o cluster vai confiar nele. Acompanhe o reingresso, confirme que o nó está de fato transmitindo e em dia, e mantenha nós saudáveis suficientes para nunca perder quórum no meio do patch.
• A imagem de nó precisa ser reproduzível. O modelo inteiro depende de a imagem corrigida ser idêntica à antiga, exceto pela camada de SO. Se as imagens divergem (uma versão diferente de extensão, uma config diferente), você descobre durante um switchover, o pior momento possível. Construa as imagens a partir da mesma definição sempre.
• Teste o switchover antes de precisar. Um switchover que você nunca rodou é um plano, não uma capacidade. Rode um controlado num período calmo, veja como a aplicação lida, meça o blip e corrija o que surpreender. Aí a noite do patch é a repetição de algo que você já sabe que funciona.

Onde complica, e quando não vale

O autor evita vender o patch rolante como perfeitamente invisível. Um switchover não é impacto zero: transações em trânsito no antigo primário são descartadas e há uma janela curta, em geral poucos segundos, em que a escrita pausa enquanto o papel migra. Para a maioria das cargas isso é um blip; para algo extremamente sensível a latência, você planeja em torno disso. De todo jeito, é muito melhor que uma indisponibilidade completa.

Alguns patches de substrato pedem mais que um reboot: uma migração de camada de storage ou uma mudança no host subjacente pode envolver mover dados, não apenas ciclar uma imagem, e isso exige plano próprio. O modelo rolante ainda se aplica, mas os passos ficam maiores.

E há o pré-requisito honesto: tudo isso pressupõe que exista um cluster. Um primário único sem réplica não faz nada disso. Se o banco é um nó só, patching de SO é genuinamente uma janela de manutenção, e a correção de verdade é o desenho de HA, não o procedimento de patch. Como diz Shahid, o patching rolante é algo que se constrói ao longo do tempo, e é uma das razões mais claras para montar HA de verdade desde o começo.

O recado final serve para qualquer DBA que ainda trata patch de SO como manutenção do banco: a última coisa que derrubou seu banco provavelmente não foi o banco, foi o chão em que ele estava apoiado. Construir o cluster para isso uma vez (imagens reproduzíveis, roteamento que segue o líder, replicação saudável, switchover testado) tira essa categoria inteira de indisponibilidade da mesa.

Fonte: Planet PostgreSQL