PostgreSQL 19: checksums de dados sem parar o servidor

O que são os checksums de dados do PostgreSQL

O PostgreSQL tem, desde a versão 9.3, um recurso chamado data checksums: uma verificação matemática gravada junto com cada página de dados no disco, usada para detectar corrupção silenciosa causada por falhas de hardware, disco ou memoria.

O problema histórico era que ativar esse recurso exigia recriar o cluster do banco do zero, algo inviável em bancos de produção grandes sem uma janela de manutenção longa. Por isso, muitos times simplesmente nunca ativavam os checksums, aceitando o risco.

O PostgreSQL 19, lançado recentemente, resolve exatamente esse ponto: agora e possível ativar (ou desativar) os checksums em um cluster já em produção, sem parar o servidor e sem precisar de dump e restore completo.

Como funciona

A mudança foi possível graças a um novo processo em segundo plano que percorre as páginas de dados existentes, calcula e grava o checksum de cada uma, enquanto o banco continua atendendo consultas e escritas normalmente.

O comando novo, executado via pg_checksums ou por uma função administrativa, coordena esse processo em fases, garantindo que nenhuma página fique sem checksum durante a transição e que o banco permaneça consistente o tempo todo.

Isso significa que um DBA pode agora habilitar checksums em um banco de 500GB em produção, monitorar o progresso, e no final ter a garantia de integridade sem nunca ter derrubado o serviço.

Principais recursos

Os pontos centrais dessa mudança no PostgreSQL 19 são:

• Ativação online: liga os checksums em um cluster rodando, sem downtime.
• Desativação online: também é possível reverter, caso o overhead de performance não compense em algum caso específico.
• Progresso monitoravel: uma view de sistema mostra quantas páginas já foram processadas.
• Segurança durante a transição: escritas concorrentes durante o processo não comprometem a consistência dos dados.
• Compatibilidade com replicas: o processo respeita replicação física sem quebrar standbys.

Como começar: instalação ou acesso passo a passo

Para usar o recurso, o primeiro passo e ter o PostgreSQL 19 instalado ou fazer o upgrade de uma versão anterior. Depois, a ativação dos checksums em um banco existente segue este fluxo:

pg_checksums --enable --progress -D /var/lib/PostgreSQL/19/main

O parâmetro --progress mostra o andamento em tempo real. Para acompanhar via SQL, enquanto o processo roda, e possível consultar a view de progresso:

SELECT * FROM pg_stat_progress_checksums;

Ao final, o banco passa a validar cada leitura de página contra o checksum gravado, alertando automaticamente se encontrar qualquer inconsistência.

Exemplo prático

Imagine uma empresa com um banco de produção de 2TB, rodando ha anos sem checksums porque ninguém queria arriscar uma janela de manutenção de horas para recriar o cluster.

Com o PostgreSQL 19, o time de infraestrutura roda o comando de ativação em um horário de menor tráfego, mas sem precisar avisar os usuários de indisponibilidade. O processo leva algumas horas rodando em segundo plano, consumindo uma fatia controlada de I/O.

Ao final, o banco emite um log confirmando que todas as páginas foram verificadas e os checksums estão ativos, sem que uma única transação tenha sido perdida ou o serviço tenha ficado fora do ar.

Comparação com alternativas

Bancos como o MySQL/InnoDB já oferecem verificação de integridade de página de forma mais simples de ativar, mas com mecanismos de detecção diferentes e menos configuráveis que o PostgreSQL.

Soluções de terceiros, como ferramentas de verificação de integridade em nível de sistema de arquivos (ZFS, por exemplo), também detectam corrupção, mas não substituem os checksums no nível do banco, que entendem a estrutura interna das páginas do PostgreSQL.

A vantagem do PostgreSQL 19 e não depender de infraestrutura externa: a checagem acontece no próprio motor do banco, de forma nativa e sem custo de licença adicional.

Pontos positivos e limitações

O maior ganho e óbvio: bancos antigos que nunca tiveam checksums agora podem ativa-los sem o antigo bloqueio operacional de recriar o cluster do zero.

A limitação e que o processo de ativação consome recursos de I/O e CPU enquanto roda, então em bancos muito grandes e recomendável monitorar o impacto e, se necessário, ajustar a velocidade do processo em ambientes com pouca folga de performance.

Além disso, checksums não são backup nem substituem estratégias de replicação e recuperação de desastre, eles apenas detectam corrupção, não a corrigem sozinhos.

Casos de uso reais

Bancos legados em produção: empresas com clusters PostgreSQL de anos que nunca ativaram checksums por medo de downtime agora tem um caminho seguro.

Setores regulados: fintechs e empresas de saúde, que precisam comprovar integridade de dados para auditorias, ganham uma camada extra de garantia.

Times de SRE e DBA: profissionais responsáveis pela confiabilidade de bancos críticos reduzem o risco de corrupção silenciosa passar despercebida por meses.

Ambientes com hardware antigo ou discos em degradação: cenários onde a chance de erro de disco e maior se beneficiam diretamente da detecção precoce.

Dicas e boas práticas

Vale a pena?

Para qualquer banco PostgreSQL em produção que ainda não tem checksums ativos, a resposta e sim: o risco de manter dados sem verificação de integridade e maior que o custo operacional de ativar o recurso agora que não exige downtime.

Times que já rodam PostgreSQL 19 ou planejam fazer upgrade em breve devem colocar a ativação dos checksums na lista de tarefas de confiabilidade do próximo trimestre.

O próximo passo e testar o processo em um ambiente de homologação antes de rodar em produção, validando o tempo estimado e o impacto de performance no seu volume de dados específico.