O Modelo de Replicação Lógica
A replicação lógica pega o mesmo log de gravação antecipada (WAL) que a replicação de streaming física envia byte a byte e, em vez disso, o decodifica em um fluxo de alterações em nível de linha: inserções, atualizações e exclusões em tabelas específicas.
Essa única mudança, de bytes para linhas, é o que permite que a replicação lógica faça coisas que a replicação física estruturalmente não pode, como replicar um subconjunto de tabelas ou mover dados entre diferentes versões principais do PostgreSQL.
Esta página constrói o modelo mental por trás de publicações, assinaturas e decodificação lógica para que as páginas mais procedurais desta seção façam sentido como aplicações de uma ideia subjacente, em vez de uma lista de recursos não relacionados.
Resumo
- A replicação lógica decodifica o WAL em alterações em nível de linha e as aplica em um assinante, em vez de replicar o banco de dados byte a byte.
- Por que é Importante: Permite sincronização seletiva de tabelas, atualizações entre versões e alimentação de sistemas downstream sem clonar um cluster inteiro.
- Conceitos-Chave: decodificação lógica, publicação, assinatura, identidade da réplica, slot de replicação lógica, worker de aplicação.
- Quando Usar: Atualizações de versão principal, replicação de um subconjunto de tabelas, alimentação de sistemas de análise ou de pesquisa e consolidação de vários bancos de dados.
- Limitações / Compromissos: DDL não se replica automaticamente, e o modelo adiciona sobrecarga de decodificação ausente na transmissão física.
- Tópicos Relacionados: replicação lógica vs. física, publicações e assinaturas, atualização com replicação lógica.
Fundamentos
O log de gravação antecipada (WAL) do PostgreSQL registra alterações em um nível baixo, próximo ao layout da página física, que é exatamente o que a replicação física deseja, mas não é diretamente utilizável como "a linha X mudou para este valor".
A decodificação lógica é o processo que lê esse WAL de baixo nível e o reconstrói em um fluxo legível de alterações lógicas, usando um plugin de decodificação para traduzir o WAL físico de volta em operações em nível de linha.
Uma publicação, criada no banco de dados de origem, nomeia o conjunto de tabelas cujas alterações devem ser expostas através deste processo de decodificação, atuando como um filtro sobre o que o restante do mecanismo jamais verá.
Uma assinatura, criada no banco de dados de destino, aponta para uma publicação, abre uma conexão de replicação e aplica continuamente as alterações que recebe através de um processo dedicado de worker de aplicação.
Pense na replicação física como fotocopiar todas as páginas de um livro-razão, enquanto a replicação lógica lê o livro-razão em voz alta e dita apenas as transações que alguém escolheu ouvir.
Esse modelo de ditado é o motivo pelo qual a replicação lógica pode conectar bancos de dados que não são idênticos, pois o assinante só precisa de tabelas e colunas correspondentes para o que ele assina, não um cluster idêntico.
Para colocar uma assinatura em funcionamento pela primeira vez, também é necessária uma sincronização inicial, uma cópia em massa das linhas existentes antes que as alterações contínuas comecem a ser aplicadas, para que um novo assinante não comece com uma tabela vazia e veja apenas as alterações a partir desse ponto.
-- Publisher: expõe duas tabelas para qualquer assinante que se conectar
CREATE PUBLICATION app_pub FOR TABLE orders, order_items;Essa única instrução é todo o modelo mental em miniatura: nomeie as tabelas, e tudo o que estiver downstream é sobre quem ouve e como eles se atualizam.
Mecânicas e Interações
A etapa de decodificação depende da identidade da réplica, uma configuração por tabela que informa ao PostgreSQL quais colunas incluir no WAL para atualizações e exclusões, para que o assinante possa corresponder à linha correta.
Por padrão, a identidade da réplica usa a chave primária da tabela, que é informação suficiente para identificar uma linha única no lado do assinante sem enviar todas as colunas em cada alteração.
Uma tabela sem chave primária precisa de REPLICA IDENTITY FULL em vez disso, que inclui a linha antiga inteira no WAL para que exclusões e atualizações ainda possam ser correspondidas, ao custo de um volume de WAL significativamente maior para essa tabela.
Cada assinatura ativa é suportada por um slot de replicação lógica no publicador, conceitualmente semelhante aos slots físicos que a replicação de streaming usa, retendo o WAL até que o assinante confirme que aplicou um determinado ponto.
Essa retenção tem a mesma dupla face dos slots físicos: protege um assinante temporariamente desconectado de perder alterações e também pode crescer o WAL ilimitadamente no publicador se um assinante desaparecer e ninguém notar.
O ponto mais agudo de todo o modelo é que DDL não se replica, o que significa que uma alteração CREATE TABLE, ALTER TABLE ou de índice feita no publicador não tem uma contraparte automática no assinante.
Esta é uma escolha deliberada, não uma falha, pois aplicar alterações de esquema arbitrárias automaticamente em um assinante que pode ter um esquema, extensões ou consumidores downstream diferentes seria muito mais perigoso do que exigir uma etapa explícita.
Na prática, as equipes lidam com isso com a disciplina de migração de expansão-contração: aplique alterações de esquema compatíveis em ambos os lados em uma ordem coordenada, usando ferramentas em vez de depender da replicação para propagar a estrutura.
Conflitos são a outra mecânica que vale a pena internalizar, pois um worker de aplicação que encontra uma violação de restrição, como uma chave duplicada de uma linha que já existe no assinante, simplesmente para de aplicar alterações até que o conflito seja resolvido por um operador.
Esse comportamento de falha-parada é intencional: pular ou sobrescrever silenciosamente dados conflitantes tornaria a replicação lógica imprevisível, então o PostgreSQL em vez disso expõe o problema ruidosamente e pausa.
Considerações Avançadas e Aplicações
Em escala, a granularidade de linha da replicação lógica se torna tanto seu maior trunfo quanto sua maior superfície operacional, pois cada tabela que você adiciona a uma publicação é uma tabela cuja identidade de réplica, custo de sincronização inicial e comportamento de conflito você agora possui.
Atualizações de versão principal são o caso de uso de assinatura do modelo, pois um assinante lógico pode executar uma versão principal mais recente do PostgreSQL do que seu publicador, o que transforma o que costumava exigir tempo de inatividade em um corte azul-verde: configure um assinante na nova versão, deixe-o alcançar, e então redirecione o tráfego.
A replicação seletiva também permite padrões arquitetônicos que a replicação física não pode, como consolidar vários bancos de dados de origem em um único data warehouse de análise, ou distribuir uma única origem para vários consumidores downstream com subconjuntos de tabelas diferentes.
Ferramentas de captura de dados de alteração como Debezium ocupam território adjacente, lendo o mesmo fluxo de decodificação lógica, mas transformando-o e roteando-o para destinos não-PostgreSQL como Kafka, o que as torna uma extensão natural deste modelo em vez de uma concorrente.
Sequências permanecem uma lacuna persistente no modelo, pois os valores de sequência não fazem parte do DML em nível de linha e historicamente exigiram sincronização manual após um corte, uma área onde as versões recentes do PostgreSQL adicionaram suporte direcionado.
| Abordagem | Granularidade | Entre versões | Melhor ajuste |
|---|---|---|---|
| Transmissão física | Cluster inteiro, byte a byte | Não, apenas a mesma versão principal | Standby de HA completo, menor sobrecarga de replicação |
| Replicação lógica | Tabelas selecionadas, nível de linha | Sim, o assinante pode ser mais novo | Sincronização seletiva, atualizações principais, fan-in/fan-out |
| Ferramentas CDC (ex: Debezium) | Nível de linha, transformável em voo | N/A, visa sistemas não-PostgreSQL | Transmitindo alterações para pipelines Kafka, de pesquisa ou de eventos |
| Foreign data wrapper | Tempo de consulta, não contínuo | N/A, lê ao vivo | Leituras ocasionais entre bancos de dados, não sincronização contínua |
O padrão que se mantém em produção é tratar a replicação lógica como um primitivo de sincronização preciso e com escopo de tabela, recorrendo à transmissão física quando o objetivo é um standby de cluster completo e reservando a replicação lógica para quando a seletividade ou a flexibilidade de versão for o requisito real.
Equívocos Comuns
- "A replicação lógica é apenas uma versão mais lenta da replicação de streaming." Ela resolve um problema completamente diferente, trocando a fidelidade de todo o cluster por seletividade em nível de tabela e compatibilidade entre versões que a replicação física não pode fornecer.
- "Alterações de esquema se propagam automaticamente como as alterações de dados." DDL é deliberadamente excluído do modelo, e alterações de esquema devem ser aplicadas ao publicador e assinante através de um processo coordenado e explícito.
- "Uma assinatura é um backup." É um mecanismo de sincronização ao vivo vulnerável às mesmas exclusões acidentais e corrupção que a origem, e não substitui a recuperação point-in-time de arquivos WAL.
- "Qualquer tabela pode ser publicada sem alterações." Uma tabela sem chave primária precisa de
REPLICA IDENTITY FULLantes que atualizações e exclusões se repliquem corretamente, e pular esta etapa quebra silenciosamente essas operações. - "Conflitos se resolvem sozinhos." Um worker de aplicação para em um conflito em vez de adivinhar a resolução, o que significa que assinaturas não monitoradas podem parar silenciosamente de aplicar alterações por longos períodos.
FAQs
O que a decodificação lógica realmente produz?
Um fluxo de eventos de alteração em nível de linha, inserção, atualização e exclusão, reconstruído a partir do WAL em vez das próprias entradas de log físico brutas.
Qual é a diferença entre uma publicação e uma assinatura?
Uma publicação, definida na origem, nomeia quais tabelas expõem alterações, enquanto uma assinatura, definida no destino, se conecta a uma publicação e aplica essas alterações localmente.
Por que a identidade da réplica é importante para atualizações e exclusões?
O assinante precisa de informações suficientes do WAL para localizar a linha correspondente, e a identidade da réplica determina exatamente quais colunas são incluídas para esse fim.
A replicação lógica propaga CREATE TABLE e ALTER TABLE?
Não, DDL é excluído por design, e alterações de esquema devem ser coordenadas manualmente ou através de ferramentas de migração em ambos os lados.
Um assinante pode executar uma versão principal mais recente do PostgreSQL do que o publicador?
Sim, e essa compatibilidade entre versões é exatamente o que torna a replicação lógica o caminho padrão para atualizações de versão principal.
O que acontece quando uma tabela não tem chave primária?
Sua identidade de réplica deve ser definida como FULL para que a linha antiga inteira esteja disponível no WAL para correspondência, pois a identidade padrão depende de uma chave primária que não existe.
A sincronização inicial é única ou contínua?
É uma cópia em massa única que é executada quando uma assinatura é iniciada pela primeira vez, após o que o worker de aplicação muda para aplicar alterações contínuas à medida que chegam.
O que acontece no publicador se um assinante se desconectar por um longo tempo?
O slot de replicação lógica retém o WAL para esse assinante indefinidamente até que ele se reconecte e alcance, o que pode aumentar o uso de disco no publicador se não for monitorado.
Como o worker de aplicação lida com uma escrita conflitante?
Ele para de aplicar mais alterações para essa assinatura em vez de sobrescrever ou pular silenciosamente a linha conflitante, expondo o problema para um operador resolver.
A replicação lógica é um substituto para backups regulares?
Não, é um mecanismo de sincronização ao vivo e não fornece a capacidade de recuperação point-in-time que o arquivamento de WAL e os backups base oferecem.
Como a replicação lógica se relaciona com ferramentas CDC como Debezium?
Debezium e ferramentas semelhantes leem o mesmo fluxo de decodificação lógica que o PostgreSQL expõe e o roteiam para sistemas externos, tornando-os uma extensão do mesmo mecanismo subjacente em vez de um separado.
Por que eu escolheria replicação lógica em vez de streaming físico para uma atualização?
A replicação física requer uma versão principal idêntica em ambos os lados, enquanto a replicação lógica permite que o assinante execute uma versão mais recente, permitindo um corte azul-verde com tempo de inatividade quase zero.
Relacionados
- Noções Básicas de Replicação Lógica - configuração prática de publicação e assinatura
- Publicações e Assinaturas - filtrando tabelas, linhas e colunas
- Lógica vs. Física - um guia prático de decisão entre os dois modelos
- Atualização com Replicação Lógica - cortes de versão principal azul-verde
- Replicação de Streaming Explicada - o modelo de replicação física com o qual este contrasta
Versões da Stack: Esta página foi escrita para PostgreSQL 18.4 (versão principal estável 18, linha de manutenção 17 também suportada).