Síncrono vs. Assíncrono
A replicação assíncrona favorece a taxa de transferência e a baixa latência de commit; a replicação síncrona reduz o RPO ao custo da latência do standby e da sensibilidade à disponibilidade.
Receita
Assíncrono por padrão na primária; adicione um standby síncrono para dados de nível 0.
-- Assíncrono (padrão): commits retornam quando o WAL local é descarregado (flushed)
ALTER SYSTEM SET synchronous_commit = 'on';
-- Síncrono para um standby nomeado
ALTER SYSTEM SET synchronous_standby_names = 'FIRST 1 (standby1)';
SELECT pg_reload_conf();-- No standby: defina application_name para corresponder a synchronous_standby_names
ALTER SYSTEM SET cluster_name = 'standby1';
SELECT pg_reload_conf();Quando usar isso: Você precisa de perda zero ou quase zero de transações confirmadas em caso de falha da primária e pode aceitar latência de commit adicional.
Exemplo de Trabalho
Meça o impacto síncrono e verifique o estado do parceiro:
-- Primária: inspecione os parceiros síncronos
SELECT application_name, sync_state, sync_priority, write_lag, flush_lag, replay_lag
FROM pg_stat_replication;
-- Compromisso de durabilidade em nível de sessão (janela de carga em lote)
SET synchronous_commit = 'off';
COPY staging.events FROM '/data/events.csv' CSV;
RESET synchronous_commit;# Compare a latência de commit assíncrona vs. síncrona (pgbench)
pgbench -h primary.db.internal -U app -c 4 -j 4 -T 30 -S appdb
pgbench -h primary.db.internal -U app -c 4 -j 4 -T 30 -S appdb \
--sync-method=strictO que isso demonstra:
synchronous_standby_namesseleciona quais standbys contam para o quórum.sync_state = 'sync'confirma que o parceiro participa dos commits síncronos.synchronous_commit = offacelera cargas em lote, mas aumenta o RPO apenas para essa sessão.
Mergulho Profundo
Como Funciona
- Assíncrono: A primária retorna
COMMITapós o descarregamento local do WAL (conformesynchronous_commit). O standby se atualiza mais tarde. - Síncrono: A primária espera até que os standbys necessários descarreguem (e opcionalmente apliquem) o WAL antes que
COMMITretorne. - Níveis de
synchronous_commit:off,local,remote_write,remote_apply,on(mapeia para o quórum desynchronous_standby_names). FIRST n (...)significa que quaisquer n standbys listados satisfazem o quórum;ANY n (...)é um estilo de quórum alternativo no PostgreSQL 18.
Instantâneo de RPO e RTO
| Modo | RPO Típico em caso de falha da primária | Latência de commit | Notas de failover |
|---|---|---|---|
| Assíncrono | Últimos segundos de WAL confirmados | Mais baixo | Promove o standby; pode perder commits recentes |
| Síncrono (1 parceiro) | Perda zero de commits se o parceiro estiver saudável | + RTT para o standby | Failover se o parceiro estiver inativo bloqueia commits, a menos que você relaxe a sincronização |
remote_apply | Perda zero; leituras no standby veem o commit | Mais alto | Maior consistência, commits mais lentos |
Nota sobre Patroni 3.x
O Patroni define synchronous_mode e gerencia synchronous_standby_names durante o failover. Teste a configuração de sincronização do Patroni em staging antes da produção; um standby síncrono perdido pode travar as escritas.
Armadilhas
- Dois standbys síncronos sem orçamento de latência - O commit espera pela réplica geográfica mais lenta. Correção: No máximo um parceiro síncrono, a menos que você modele o RTT da WAN.
- Parceiro síncrono inativo - As escritas travam se o quórum não puder ser atendido. Correção: Política de failover do Patroni ou reduza temporariamente
synchronous_standby_names. synchronous_commit = offglobalmente - Rápido, mas o RPO aumenta para todas as sessões. Correção: Limite a janelas de manutenção ou apenas funções de lote.application_namecom nome incorreto - O standby nunca se torna um parceiro síncrono. Correção: Corresponda aos nomes empg_stat_replication.application_name.- Confundir sincronização com replicação lógica - Protocolo e garantias diferentes. Correção: A sincronização física é o quórum do WAL; a lógica é o fluxo de alterações.
Alternativas
| Alternativa | Use Quando | Não Use Quando |
|---|---|---|
| Assíncrono + backups base frequentes | DR entre regiões com RPO flexível | O livro-razão financeiro precisa de perda zero |
| Replicação lógica | Upgrade de versão, tabelas seletivas | Você precisa de quórum físico síncrono |
synchronous_commit = remote_write | Equilíbrio entre latência e durabilidade | Você requer visibilidade de replay do standby antes do commit |
FAQs
Quantos standbys síncronos devo executar?
Um parceiro síncrono local é o padrão de produção comum. Mais parceiros aumentam a latência e os modos de falha.
A replicação síncrona bloqueia leituras na primária?
Não. Apenas as transações de commit esperam o reconhecimento do standby.
O que acontece se o standby síncrono morrer?
Os commits travam até que o quórum seja restaurado ou você altere synchronous_standby_names. O Patroni pode rebaixar o modo síncrono automaticamente.
O `remote_apply` é sempre melhor?
Ele espera pelo replay do standby, não apenas pelo descarregamento. Use apenas quando os aplicativos leem do standby imediatamente após o commit.
O PgBouncer pode afetar o comportamento síncrono?
O PgBouncer agrupa conexões, mas não altera as semânticas síncronas do PostgreSQL. Configurações de sessão como synchronous_commit se aplicam por conexão de backend.
Relacionados
- Noções Básicas de Replicação de Streaming - configuração
- Slots de Replicação - retenção de WAL
- Patroni & etcd/Consul - automação do modo síncrono
- Noções Básicas de DR - definições de RPO/RTO
Versões da Stack: Esta página foi escrita para PostgreSQL 18.4 (estável 18, manutenção 17), pgvector 0.8+, PgBouncer 1.x, Patroni 3.x e PostGIS 3.5+.