Réplicas de leitura e atraso de replicação: como se manifestam as leituras desatualizadas e como limitá-las

O que é

Na replicação em streaming do PostgreSQL, o primário envia registros do write-ahead log (WAL) aos standbys, que os reaplicam; um hot standby também atende consultas somente leitura. A replicação é assíncrona por padrão: um commit retorna antes de qualquer standby ter os dados. A documentação (citada) descreve níveis de synchronous_commit que fazem o commit esperar até que um standby tenha gravado, descarregado (flush) ou, com remote_apply, reaplicado a transação, de modo que ela fique visível para consultas nesse standby. Segundo a documentação, isso permite balanceamento de carga com consistência causal em casos simples; os standbys envolvidos são indicados em synchronous_standby_names.

A reaplicação e as consultas competem entre si. A documentação do hot standby (citada) explica que a aplicação do WAL pode entrar em conflito com consultas em execução (por exemplo, quando uma linha de que a consulta precisa já foi removida pela limpeza no primário); após max_standby_streaming_delay, a consulta em conflito é cancelada. Já hot_standby_feedback impede que o VACUUM do primário remova linhas de que um standby ainda precisa, ao custo de bloat no primário. O monitoramento usa pg_stat_replication no primário e, no standby, as funções de posição de replay (citadas), como pg_last_wal_replay_lsn().

Por que importa

O bug típico: um usuário envia um formulário (escrita no primário), a página seguinte lista os itens (leitura na réplica) e o novo item não aparece; ao tentar de novo, ele aparece. Jobs em segundo plano que leem de uma réplica agem sobre um estado desatualizado. Não se trata de casos de borda raros, e sim do comportamento normal quando há atraso.

Como aplicar

• Classifique as leituras: leituras após uma escrita no mesmo fluxo do usuário vão para o primário, ou ficam fixadas nele por um curto período após qualquer escrita daquela sessão; dashboards e buscas podem usar réplicas livremente.
• Para uma verificação estrita de read-your-writes, registre a posição de commit do primário e só deixe a leitura na réplica prosseguir quando a posição de replay dela a tiver alcançado.
• Dê às réplicas analíticas um atraso de standby grande, para que consultas longas não sejam canceladas; mantenha o atraso curto nas réplicas que atendem leituras sensíveis à latência.
• Configure alertas para o atraso em bytes e em segundos e para o número de cancelamentos de consultas em cada standby.
• Use modos síncronos somente para os standbys e cargas de trabalho em que se aceitem a latência adicional de commit e o risco de commits travados quando um standby estiver fora do ar.

Armadilhas

Um proxy que direciona instruções por tipo (todo SELECT para uma réplica) pode enviar as leituras da própria transação para longe do primário, a menos que acompanhe a transação. Uma réplica promovida durante um failover pode estar atrasada em relação ao antigo primário, de modo que commits recentes podem ser perdidos com replicação assíncrona. O atraso sob carga pesada de escrita cresce justamente quando as leituras são mais intensas.