Replication slots no PostgreSQL: a rede de segurança que pode afundar seu disco

Replication slots são um recurso pequeno com um raio de impacto enorme. Eles impedem que suas réplicas quebrem — e, quando um é esquecido, são a forma mais comum de um primário PostgreSQL encher o disco e travar. Entender os dois lados é essencial.

O problema que os slots resolvem

O primário recicla segmentos antigos de WAL para liberar disco. Mas se um standby fica brevemente offline e o WAL que ele ainda precisa já foi reciclado, a replicação quebra com o temido "requested WAL segment has already been removed" — e a única correção é reconstruir o standby do zero.

Um replication slot é a promessa do primário: "não vou descartar WAL até este consumidor específico confirmá-lo." Isso torna a replicação durável entre reinícios do standby e quedas de rede.

Dois tipos de slot

-- Slot físico (para réplicas por streaming)
SELECT pg_create_physical_replication_slot('standby1');

-- Slot lógico (para replicação lógica / CDC como Debezium)
SELECT pg_create_logical_replication_slot('cdc_slot', 'pgoutput');

Inspecione todos em uma única view:

SELECT slot_name, slot_type, active,
       pg_size_pretty(
         pg_wal_lsn_diff(pg_current_wal_lsn(), restart_lsn)
       ) AS retained_wal
FROM pg_replication_slots;

O lado sombrio: risco de encher o disco

A mesma promessa que protege vira arma quando um consumidor some. Se um slot fica active = false e nunca volta — uma réplica desativada, um conector CDC que caiu — seu restart_lsn para de avançar. O primário guarda cada segmento de WAL a partir daí, para sempre. O pg_wal cresce até o disco encher e o primário para de aceitar escritas. Esse é um dos outages mais comuns de PostgreSQL na prática.

A trava de segurança: max_slot_wal_keep_size

Desde o PostgreSQL 13 você pode limitar quanto WAL um slot pode reter:

-- postgresql.conf
max_slot_wal_keep_size = 50GB

Passado esse limite, o PostgreSQL invalida o slot atrasado em vez de encher o disco. Você perde aquela réplica (precisa reconstruí-la), mas o primário sobrevive — em geral a troca certa. Verifique slots invalidados pela coluna wal_status (extended, unreserved, lost).

Derrube o que não usa

SELECT pg_drop_replication_slot('old_standby');

Todo slot criado é uma promessa permanente. Desativar uma réplica sem derrubar seu slot é exatamente como o incidente de disco cheio começa.

Por que você quer isso vigiado automaticamente

Um slot inativo é invisível até o alarme de disco disparar às 3 da manhã. O PG Monitoring reporta continuamente o tamanho de WAL retido, o status ativo e a tendência de crescimento de cada slot, e levanta um alerta quando um slot fica inativo ainda prendendo WAL — transformando um outage de madrugada em um chamado de rotina.