Streaming Replication Explicada
A replicação de streaming é o mecanismo que mantém uma segunda instância do PostgreSQL continuamente sincronizada com uma primária, enviando o mesmo log de escrita antecipada (WAL) que a primária já escreve para recuperação de falhas.
Ela pertence à família de replicação física, que copia o banco de dados no nível de bytes, em vez de raciocinar sobre linhas ou instruções individuais.
Entendê-la é importante porque quase todas as estratégias de alta disponibilidade, escalonamento de leitura e backup no PostgreSQL começam a partir deste único primitivo, e as páginas de como fazer nesta seção assumem que você já tem esse modelo mental em vigor.
Resumo
- A replicação de streaming envia continuamente registros do write-ahead log (WAL) de uma primária para uma ou mais standbys, que os reprocessam para permanecerem byte a byte idênticas à primária.
- Por que Importa: É a base para failover, backups sem tempo de inatividade e escalonamento de leitura, e quase nada mais na história de HA do PostgreSQL funciona sem ela.
- Conceitos Chave: WAL, WAL sender, WAL receiver, replication slot, synchronous commit, cascading replica.
- Quando Usar: Qualquer carga de trabalho que precise de um standby promovível e ativo (hot standby), tráfego de leitura descarregado ou uma fonte de backup com baixo RPO.
- Limitações / Trade-offs: Ela replica todo o cluster byte a byte, então você não pode filtrar tabelas ou transitar entre versões principais como a replicação lógica pode.
- Tópicos Relacionados: commit síncrono vs. assíncrono, slots de replicação, réplicas em cascata, alta disponibilidade e failover.
Fundamentos
Toda escrita no PostgreSQL primeiro aterrissa no write-ahead log, um registro durável e somente de adição de todas as alterações feitas no banco de dados antes que essa alteração seja aplicada aos arquivos de dados reais.
Este design existe para recuperação de falhas, pois reprocessar o WAL após uma falha reconstrói exatamente o estado em que o banco de dados estava antes de cair.
A replicação de streaming reutiliza o mesmo log para um segundo propósito: em vez de apenas reprocessar o WAL localmente após uma falha, um processo WAL sender na primária o transmite pela rede para um processo WAL receiver em uma standby, continuamente e em tempo quase real.
O processo de recuperação da standby reprocessa esse WAL exatamente como faria após sua própria falha, e é por isso que uma standby de streaming é frequentemente descrita como estando em um estado permanente e contínuo de recuperação de falhas.
Como a standby está reprocessando o WAL real da primária em vez de reexecutar instruções SQL, ela acaba sendo uma cópia física byte a byte, incluindo índices, preenchimento (bloat) de tabelas e até mesmo o mesmo layout de página.
Uma analogia útil é um mensageiro que lê o diário de uma primária em voz alta em tempo real para um segundo escriba, que copia cada palavra literalmente em vez de resumir os eventos descritos.
Essa natureza literal é tanto a característica quanto a restrição: uma standby não pode selecionar quais tabelas receber, não pode rodar uma versão principal diferente e não pode aceitar escritas próprias até que pare completamente de seguir a primária.
Parar e trocar de papéis é chamado de promoção, o momento em que uma standby sai da recuperação, começa a aceitar escritas e se torna uma primária por si só.
Mecânicas e Interações
A primária não simplesmente envia WAL para uma standby e a esquece, pois o PostgreSQL suporta vários níveis de synchronous commit que mudam quando a transação de um cliente pode relatar sucesso.
No nível mais solto, a replicação assíncrona permite que a primária confirme e reconheça o cliente antes que qualquer standby confirme o recebimento, o que minimiza a latência de confirmação, mas aceita que uma falha em um momento muito ruim pode perder as transações mais recentes.
No nível mais rigoroso, os níveis de commit síncrono fazem a primária esperar que uma ou mais standbys confirmem o WAL antes que o commit do cliente retorne, trocando latência por uma garantia de durabilidade que sobrevive a uma falha de nó único.
A configuração synchronous_standby_names controla quais standbys participam e quantas devem confirmar, e o PostgreSQL suporta grupos de estilo de quórum para que um commit possa esperar por quaisquer duas de três standbys elegíveis em vez de um nó nomeado específico.
-- Exige confirmação de quaisquer 2 de 3 standbys nomeadas antes que o commit retorne
ALTER SYSTEM SET synchronous_standby_names = 'ANY 2 (standby1, standby2, standby3)';Essa única configuração é a alavanca que transforma o mesmo mecanismo subjacente de envio de WAL em um pipeline assíncrono de baixa latência ou em um cluster síncrono fortemente durável, e escolher entre eles é realmente escolher quanta latência de commit você está disposto a pagar por quanta proteção contra perda de dados.
Uma segunda mecânica que vale a pena internalizar é a retenção de replication slot, pois um slot diz à primária para manter o WAL no disco até que a standby correspondente confirme que o recebeu e o aplicou.
Sem um slot, uma primária é livre para reciclar segmentos de WAL antigos assim que não precisar mais deles para sua própria recuperação de falhas, o que significa que uma standby que fica muito para trás pode descobrir que o WAL que ela precisa já foi excluído.
Com um slot, a primária retém o WAL indefinidamente para essa standby, o que protege contra exatamente esse modo de falha, mas introduz um novo: uma standby que fica offline e nunca volta pode encher silenciosamente o disco da primária.
As standbys não se limitam a um único salto da primária, pois uma standby pode atuar como fonte para outras standbys em uma topologia em cascata, retransmitindo o WAL que já recebeu em vez de exigir que cada standby se conecte diretamente à primária.
A cascata existe principalmente para proteger a primária da sobrecarga de conexão e CPU à medida que o número de standbys cresce, não para reduzir o lag de replicação, pois cada salto adicional em uma cascata geralmente adiciona uma pequena quantidade de lag em vez de removê-lo.
Considerações Avançadas e Aplicações
Em escala, a questão operacional muda de "a replicação funciona" para "o que acontece quando ela fica para trás ou quebra", e a resposta depende muito de qual nível de commit síncrono você escolheu e como sua camada de orquestração reage a ele.
Uma standby síncrona que fica offline não apenas para de receber atualizações, mas pode bloquear todas as escritas na primária até que ela se reconecte ou seja removida de synchronous_standby_names, e é por isso que configurações síncronas de produção quase sempre usam um quórum de várias standbys em vez de uma única nomeada.
Réplicas atrasadas (delayed replicas), standbys configuradas para reprocessar o WAL após um atraso de tempo deliberado, oferecem uma rede de segurança contra erros lógicos como um delete em massa acidental, pois o atraso dá aos operadores uma janela para intervir antes que a instrução danosa se replique.
Topologias entre regiões adicionam latência de rede ao mesmo espaço de trade-off, pois uma standby síncrona através de um link WAN pode adicionar dezenas ou centenas de milissegundos a cada commit, o que leva muitas equipes a optarem por réplicas assíncronas entre regiões emparelhadas com réplicas síncronas na mesma região.
Ferramentas de orquestração como Patroni 3.x ficam por cima de todo esse mecanismo, usando as próprias visualizações de status de replicação do PostgreSQL para decidir qual standby é elegível para promoção e para automatizar o failover que a replicação de streaming sozinha não fornece.
| Nível Síncrono | Garantia de Durabilidade | Custo de Latência de Commit | Melhor Ajuste |
|---|---|---|---|
off (async) | Standby pode ter lag arbitrário; commits recentes podem ser perdidos em falha da primária | Nenhum | Réplicas de leitura, DR entre regiões onde a latência domina |
local | WAL da própria primária gravado em disco; sem garantia de standby | Mínimo | Durabilidade local sem garantias de replicação |
remote_write | Standby recebeu WAL nos buffers do SO, ainda não gravado em disco | Moderado | Equilíbrio de segurança e latência para a maioria das configurações síncronas |
on | Standby gravou WAL em disco | Mais Alto | Dados Tier-0 onde perder uma transação confirmada é inaceitável |
remote_apply | Standby reprocessou WAL, visível para leituras da standby | Mais Alto | Consistência de leitura após escrita na própria standby |
A lição arquitetural mais profunda é que a replicação de streaming lhe dá um dial, não uma única resposta, e o nível síncrono correto é uma decisão de negócios sobre perda de dados aceitável disfarçada de configuração de banco de dados.
Equívocos Comuns
- "Replicação assíncrona significa que definitivamente perderei dados eventualmente." A perda de dados só ocorre se a primária falhar antes que o WAL de uma transação não confirmada chegue a uma standby, o que, para uma standby saudável e com baixo lag, é uma janela estreita em vez de uma certeza.
- "Uma standby síncrona garante zero perda de dados, não importa o quê." Ela garante zero perda apenas para as standbys específicas nomeadas em
synchronous_standby_names, então um quórum mal configurado pode silenciosamente deixá-lo com garantias mais fracas do que o assumido. - "Mais níveis em cascata sempre aumentam o lag proporcionalmente." Cada salto adiciona algum lag, mas uma cascata bem provisionada com links intra-região rápidos geralmente adiciona apenas milissegundos por nível, muito menos do que um único link entre regiões congestionado.
- "Slots de replicação são estritamente um recurso de segurança sem desvantagens." Um slot para uma standby offline retém o WAL para sempre, o que encheu discos de primária e derrubou clusters de produção quando ninguém estava monitorando slots inativos.
- "Replicação de streaming e replicação lógica são intercambiáveis." A replicação de streaming clona todo o cluster byte a byte, enquanto a replicação lógica move alterações em nível de linha para tabelas selecionadas, e os dois resolvem problemas genuinamente diferentes.
FAQs
O que exatamente é enviado pela rede na replicação de streaming?
Registros WAL brutos, as mesmas entradas de log de baixo nível que o PostgreSQL escreve para sua própria recuperação de falhas, são transmitidos byte a byte para a standby em vez de instruções SQL ou diferenças de linha.
Por que uma standby de streaming é descrita como estando em recuperação permanente?
O processo de recuperação da standby reprocessa o WAL recebido exatamente como faria após uma falha, e ela nunca sai desse loop de reprocessamento até ser promovida.
A replicação de streaming me permite escolher quais tabelas são replicadas?
Não, ela replica todo o cluster físico, e a seletividade em nível de tabela é uma capacidade da replicação lógica em vez disso.
Qual é a diferença prática entre commit síncrono e assíncrono aqui?
O commit síncrono faz a primária esperar pela confirmação de uma standby antes de retornar sucesso ao cliente, enquanto o commit assíncrono retorna imediatamente e deixa a replicação se atualizar depois.
Uma standby síncrona pode bloquear escritas na primária?
Sim, se ela estiver inacessível e ainda listada em synchronous_standby_names, cada commit que espera por sua confirmação ficará paralisado até que ela se reconecte ou seja removida do quórum.
Contra o que um slot de replicação realmente protege?
Ele impede que a primária recicle segmentos de WAL que uma standby atrasada ainda precisa, ao custo de retenção ilimitada de WAL se essa standby nunca se reconectar.
Por que eu usaria uma réplica em cascata em vez de conectar cada standby à primária?
A cascata distribui a carga de trabalho de envio de WAL entre vários nós, reduzindo a pressão de conexão e CPU na primária à medida que o número de standbys aumenta.
Promoção é a mesma coisa que failover?
Promoção é o passo mecânico onde uma standby sai da recuperação e começa a aceitar escritas, enquanto failover é o processo mais amplo, frequentemente automatizado por ferramentas como Patroni, que decide quando e qual standby promover.
Quão atualizados estão os dados de uma standby a qualquer momento?
Exatamente tão atualizados quanto o WAL que ela recebeu e reprocessou, e é por isso que o lag de reprocessamento, não o tempo de relógio, é a maneira correta de raciocinar sobre a atualidade da standby.
Para que serve uma réplica atrasada?
Ela intencionalmente reprocessa o WAL após um atraso configurado, criando uma janela para capturar e intervir antes que uma instrução destrutiva como um delete em massa acidental chegue até ela.
A replicação de streaming entre regiões sempre precisa ser assíncrona?
Nem sempre, mas a latência de rede adicionada de uma standby síncrona entre regiões é significativa o suficiente para que a maioria das equipes reserve o commit síncrono para standbys na mesma região e use assíncrono para as distantes.
Qual papel um orquestrador como Patroni desempenha sobre a replicação de streaming?
Patroni monitora o status de replicação do próprio PostgreSQL para decidir qual standby está saudável e atual o suficiente para ser promovida, então automatiza a promoção que a replicação de streaming em si não inicia por conta própria.
Relacionados
- Streaming Replication Basics - configuração prática para uma única standby assíncrona
- Synchronous vs Asynchronous - escolhendo um nível de commit na prática
- Replication Slots - configurando a retenção de WAL baseada em slots
- Cascading Replicas - topologias de standby multi-salto
- HA & Failover Key Points - como a replicação alimenta o failover automatizado
Versões da Stack: Esta página foi escrita para PostgreSQL 18.4 (principal estável 18, linha de manutenção 17 também suportada) e Patroni 3.x.