Replicação lógica no PostgreSQL: publicações, assinaturas e diferenças em relação à replicação por streaming

O que é

A replicação física (streaming) envia registros do write-ahead log (WAL) a um standby, que os reproduz bloco a bloco. A documentação do standby afirma que a arquitetura de hardware precisa ser a mesma e que, em geral, não é possível fazer log shipping entre versões principais diferentes. A replicação lógica, segundo o capítulo citado, replica objetos de dados e suas alterações com base na identidade de replicação deles (normalmente uma chave primária), num modelo de publicação e assinatura (publish-and-subscribe). O publicador define uma publicação sobre tabelas (opcionalmente limitada a INSERT, UPDATE, DELETE ou TRUNCATE, com filtros de linhas e listas de colunas) e o assinante cria uma assinatura. Um snapshot inicial copia as linhas existentes, e as alterações posteriores são aplicadas na ordem de commit, o que a documentação chama de replicação transacional. Cada assinatura consome as alterações por meio de um slot de replicação no publicador.

Por que importa

Um standby de streaming é uma cópia completa, útil para failover e para escalar leituras; não aceita escrita e não pode ser seletivo. A replicação lógica leva um subconjunto de tabelas para um banco que pode ter outra versão principal ou outra plataforma, servir de destino de consolidação para análise ou ser um assinante que também mantém tabelas próprias. A lista de casos de uso do capítulo inclui a replicação entre versões principais, o que permite uma atualização com troca em poucos segundos.

Como aplicar

• Dê uma chave primária a cada tabela publicada. Uma tabela sem chave adequada precisa de REPLICA IDENTITY FULL, que a documentação descreve como alternativa de último recurso, com buscas de linhas ineficientes no assinante.
• Copie o esquema manualmente antes (pg_dump --schema-only): a página de restrições informa que o esquema do banco e os comandos DDL não são replicados e recomenda aplicar primeiro no assinante as alterações de esquema que apenas adicionam objetos.
• Planeje as sequências: os dados de sequências não são replicados. Antes da troca (switchover), defina as sequências do assinante com valores acima dos valores atuais do publicador.
• Monitore o slot. Um assinante fora do ar mantém o seu slot, e o slot mantém o WAL no publicador até o disco encher. max_slot_wal_keep_size limita essa retenção, ao custo de invalidar um slot que fique atrasado demais.
• Trate as tabelas replicadas como somente leitura no assinante. A página de conflitos afirma que as alterações recebidas são aplicadas mesmo que a linha tenha sido modificada localmente, e que dados recebidos que violem uma restrição (por exemplo, uma linha local com a mesma chave única) interrompem a replicação até que o problema seja resolvido manualmente.

Armadilhas

Objetos grandes (large objects) não são replicados, e views, views materializadas e tabelas externas (foreign tables) não podem ser publicadas. Uma alteração de esquema no publicador que a tabela do assinante não consiga aceitar interrompe a replicação até que o assinante seja corrigido. A replicação lógica não é um backup: um DELETE ou TRUNCATE no publicador é aplicado fielmente.