Melhores Práticas de Replicação por Streaming

No máximo um parceiro síncrono, a menos que você entenda a latência. Estas regras mantêm a replicação física confiável sob picos de carga e failover.

Como Usar Esta Lista

• Aplique durante o design do cluster e a cada adição de standby.
• Verifique cada item após alterações de configuração do Patroni ou atualizações do sistema operacional.
• Use como um checklist de treinamento pré-failover.
• Combine com alertas do Grafana sobre lag de bytes e slots inativos.

A - Topologia e Slots

• Um slot de replicação física por standby de longa duração. Slots evitam perda de WAL durante interrupções.
• Nomeie os slots com base no nome do host ou membro do Patroni. Operadores sabem qual consumidor corrigir.
• Defina max_slot_wal_keep_size como uma válvula de segurança de disco. Complementa, não substitui, a higiene de slots.
• Limite a profundidade de cascata a dois saltos. Saltos extras multiplicam o lag e os domínios de falha.
• Direcione standbys para candidatos a failover. As pontas de cascata permanecem somente leitura, a menos que o runbook diga o contrário.

B - Sincronia e Durabilidade

• No máximo um parceiro síncrono em produção. Mais parceiros exigem um orçamento explícito de latência WAN.
• Combine application_name com synchronous_standby_names. Standbys com nomes incorretos nunca entram em quórum.
• Documente o comportamento quando o parceiro síncrono estiver inativo. O Patroni deve rebaixar o síncrono ou os ops devem relaxar o quórum rapidamente.
• Evite synchronous_commit = off global. Escopo de degradações de durabilidade apenas para funções de lote.
• Prefira remote_write em vez de remote_apply, a menos que os aplicativos leiam do standby pós-commit. Menor latência de commit.

C - Monitoramento e Alertas

• Alerta sobre lag de bytes em pg_stat_replication, não apenas lag de tempo. Cargas de trabalho ociosas escondem atraso no gap LSN.
• Acione um alerta quando o último standby síncrono parar de transmitir. Gravações podem travar em modo síncrono.
• Alerta sobre slots inativos retendo > 512 MiB de WAL. Slots órfãos preenchem discos.
• Monitore a taxa de geração de WAL no primário. Picos preveem pressão de replicação.
• Acompanhe a função de líder do Patroni separadamente do lag de replicação. Clientes podem estar no host errado enquanto o lag parece bom.

D - Segurança e Rede

• Use scram-sha-256 para usuários de replicação em pg_hba.conf. Sem senhas em texto plano nos arquivos de configuração.
• TLS na replicação (sslmode=verify-full em primary_conninfo). Criptografe links entre AZs e entre regiões.
• Usuário de replicação dedicado com privilégios mínimos. Apenas login REPLICATION, sem superusuário.
• Função de monitoramento separada para consultas de saúde. Sem superusuário para verificações de cron.

E - Operações e Treinamentos

• Reúna a promoção de standby trimestralmente. Meça o RTO com testes de reconexão de aplicativos.
• Verifique se o PgBouncer ou HAProxy roteiam para o novo primário após a promoção. O pool não corrige o DNS sozinho.
• Reencha o standby com pg_basebackup após wal_status = lost. O catch-up incremental não pode corrigir WAL ausente.
• Mantenha as versões principais do primário e do standby alinhadas. A replicação física não cruza versões principais.

FAQs

Relacionados

• Noções Básicas de Replicação por Streaming - walkthrough de configuração
• Síncrono vs. Assíncrono - trade-offs de RPO
• Slots de Replicação - mecânica de retenção
• Melhores Práticas de HA - treinamentos de failover

Versões da Stack: Esta página foi escrita para PostgreSQL 18.4 (estável 18, manutenção 17), pgvector 0.8+, PgBouncer 1.x, Patroni 3.x e PostGIS 3.5+.