Purge The Purge

Como funcionam os processos de purga automática em ambientes de produção

Vim para o trabalho num dia de terça e descobri que os discos do servidor de banco de dados tinham atingido 98% de utilização. O problema não era falta de espaço — era uma tabela de logs que acumulava registos há 14 meses sem qualquer política de retenção. Passámos três dias a recuperar o controlo. Desde então, aprendi uma coisa simples: a purga não se faz quando já é tarde demais. O conceito de purge the purge refere-se à ideia de gerir ativamente os ciclos de eliminação de dados, artefactos e recursos obsoletos nos sistemas onde operas. Não é só apagar ficheiros antigos. É criar um sistema que se mantém limpo sozinho, com regras claras, monitorização e fallback.

purge the purge na prática

O primeiro passo é identificar o que está a acumular. Na minha experiência, os maiores culpados são: imagens de Docker não referenciadas, branches abandonados no repositório, artefactos de build, sessões de utilizador expiradas, tabelas de histórico sem data de expiração e backups antigos que ninguém vai recuperar. Começa por fazer um inventário. Conta linhas, mede gigabytes, lista frequência de acesso. Depois classifica cada grupo como ativo, sazonal ou morto. A classificação é a parte mais importante e a que mais gente ignora. Um backup de 2022 pode ser morto ou sazonal, dependendo do contexto regulamentar. Se a tua empresa está sujeita a retenção fiscal de cinco anos, esse backup não é morto. É sazonal. Se não há obrigação legal, é morto. Confundir estas duas categorias gera dois tipos de erro: apagar o que precisas mais tarde ou manter o que não precisa existir.

Depois da classificação, implementas regras automáticas. Cada sistema tem a sua ferramenta. No PostgreSQL, usas queries com DELETE baseado em timestamps e particionamento por intervalo. No Docker, docker system prune -a --filter until=48h resolve a maioria dos casos. Em git, scripts de hook que removem branches com mais de 30 dias sem commits recentes. O ponto crucial é que essas regras têm de rodar sozinhas e gerar logs de auditoria. Sem log, não há forma de saber o que foi apagado e porquê. Eu costumo estruturar o cron como um pipeline em três fases. Fase um: limpeza de artefactos óbvios, sem impacto. Artefactos de build com mais de 7 dias, imagens não referenciadas com mais de 24 horas, sessões com token expirado. Fase dois: purga de dados históricos com janela de segurança. Isto é o que mais causa dores de cabeça. Eu faço sempre uma cópia de retenção de 48 horas antes de executar a limpeza real. Se algo correr mal, recupero com backup, não com adivinhação. Fase três: compactação e verificação de integridade pós-purga. Aqui confio em checksums e na validação de contagens de linhas antes e depois. A diferença entre as contagens tem de bater com o esperado.

Um erro comum que vejo é aplicar a mesma política a todos os ambientes. Produção e desenvolvimento não são iguais. No dev, a purga pode ser agressiva. Em produção, cada limpeza tem de passar por um gate de aprovação. Eu uso variáveis de ambiente para controlar o modo de operação: PURGE_MODE=strict para produção, PURGE_MODE=aggressive para homologação. Isto evita que um script mal configurado elimine dados produtivos durante um deploy às três da manhã. Há casos em que a purga automática falha completamente. Quando há foreign keys ativas que impedem a eliminação de registos referenciados, ou quando os dados estão distribuídos por múltiplas regiões com latência significativa. Nestas situações, a solução mais simples é particionar a tabela antes de tudo. Partições por mês facilitam a eliminação de lotes inteiros sem locks prolongados. Já vi tabelas de eventos que levavam quatro horas para limpar e, após a partição, o mesmo processo dura 12 minutos. A diferença não é mágica, é física. Eliminar uma partição é muito mais rápido do que fazer DELETE com WHERE massivo.

Outra armadilha frequente é a purga de logs de aplicação sem análise prévia. Logs contêm informação valiosa sobre erros e padrões de uso. Antes de configurar retenção automática, garante que estás a enviar logs para um sistema centralizado como Loki ou ELK. Só depois de confirmada a ingestão é que aplicas retenção de 30 dias nos logs locais. Eu já perdi investigação de um incidente porque o log que teria revelado a causa raiz tinha sido apagado por um script que eu próprio configurei. Aprendi a lição da pior forma possível. Se quiseres começar agora, o primeiro passo prático é simples. Executa uma query para identificar tabelas com mais de 10 milhões de linhas que não tenham sido atualizadas nos últimos 90 dias. Em MySQL: SHOW TABLE STATUS LIKE 'nome_tabela';. Em PostgreSQL, consulta a pg_stat_user_tables. A partir daí, constrói um script que elimine lotes de 10 mil linhas por vez, com sleep de 500ms entre lotes, para não saturar o I/O do disco. O número 10 mil funciona bem na maioria dos casos. Se o teu servidor for lento, reduz para 5 mil. Se for rápido, testa com 25 mil.

Não existe solução universal. O que funciona num servidor com SSD NVMe em ambiente cloud pode destruir um servidor com discos mecânicos em infraestrutura on-premise. Testa sempre em staging primeiro, com dados reais ou dados sintéticos que representem fielmente a produção. E guarda sempre os logs de execução. Se um dia precisares de justificar porquê que tal tabela foi esvaziada, o log é a tua única defesa.