Práticas Recomendadas de Replicação Lógica

Fique atento às limitações de DDL; alterações de esquema são difíceis. Estas regras mantêm a replicação lógica estável entre atualizações e evolução de esquema.

Como Usar Esta Lista

• Revise antes de adicionar tabelas a uma publicação.
• Use como um checklist durante os cutovers de atualização de versão principal entre blue/green.
• Combine com alertas sobre o atraso em bytes dos slots lógicos.
• Compartilhe com as equipes de aplicação que gerenciam migrações de DDL.

A - Esquema e Identidade

• Toda tabela publicada deve ter uma chave primária ou REPLICA IDENTITY explícito. Atualizações e exclusões são replicadas de forma confiável.
• Prefira REPLICA IDENTITY DEFAULT (PK) em vez de FULL quando possível. FULL aumenta o volume de WAL.
• Crie o esquema do assinante antes de CREATE SUBSCRIPTION. Tabelas, tipos e índices devem existir no assinante.
• Trate DDL como uma migração coordenada em ambos os lados. A replicação lógica não aplica ALTER TABLE automaticamente.
• Use expandir-contração para alterações de coluna. Adicione a coluna primeiro no assinante, depois no publicador, e então preencha os dados.

B - Publicações e Assinaturas

• Prefira listas explícitas de tabelas em vez de FOR ALL TABLES em produção. Evite a replicação acidental de tabelas sensíveis.
• Execute ALTER SUBSCRIPTION ... REFRESH PUBLICATION após ADD TABLE. Novas tabelas não são copiadas de outra forma.
• Documente filtros de linha como predicados imutáveis. Funções voláteis quebram definições de publicação.
• Um slot lógico por assinatura; nomeie os slots claramente. Slots órfãos enchem o disco do publicador.
• Descarte assinaturas com DROP SUBSCRIPTION para limpar os slots do publicador. Descarte manual de slots se a conexão estiver bloqueada.

C - Operações e Atraso

• Crie alertas para o atraso em bytes do confirmed_flush_lsn do slot lógico. Mesmo risco de disco que slots físicos.
• Pause assinaturas (enabled = false) durante a manutenção do assinante. Retome com verificação de atraso.
• Mantenha as tabelas do assinante somente leitura para dados publicados. Conflitos param os workers de aplicação.
• Sincronize sequências antes do cutover em atualizações principais. Evite erros de chave duplicada no PG 18.4 green.
• Não roteie assinaturas através do pool de transações do PgBouncer. Use conexões diretas com PostgreSQL.

D - Topologia e HA

• Não substitua HA físico por lógico apenas para tier-0. Mantenha o standby físico do Patroni para failover.
• Dimensiona max_replication_slots e max_wal_senders para consumidores lógicos + físicos. Carga combinada no primário.
• Verifique a sincronização de slots do Patroni 3.x após o failover. Slots lógicos devem existir no novo primário.
• Teste o caminho de atualização principal em staging trimestralmente. Meça a janela de congelamento e a sincronização de sequências.

E - Segurança e Conformidade

• TLS na string de CONNECTION da assinatura (sslmode=verify-full). Criptografe a replicação entre redes.
• Usuário de replicação dedicado por assinante. Privilégio mínimo no publicador.
• Listas de colunas para minimização de PII a jusante. Filtros de linha não substituem a autorização no assinante.
• Audite quem pode CREATE PUBLICATION. Publicações expõem fluxos de alteração.

FAQs

Relacionados

• Noções Básicas de Replicação Lógica - configuração
• Publicações e Assinaturas - filtros
• Atualizar com Replicação Lógica - cutover de versão principal
• Slots de Replicação - monitoramento de slots

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