Réplicas entre Regiões

Réplicas entre regiões fornecem uma cópia quente somente leitura em outra geografia. Elas são quase sempre assíncronas; aceite o atraso de replicação como seu RPO entre regiões, a menos que você invista em arquiteturas síncronas especializadas.

Receita

Primária em us-east, secundária assíncrona em eu-west para leitura de recuperação de desastres e candidata à promoção.

# Secundária em eu-west tem como alvo a primária em us-east via primary_conninfo
# Use TLS e caminho de rede de replicação dedicado

-- Na primária: monitorar a secundária entre regiões
SELECT application_name, client_addr,
       pg_wal_lsn_diff(sent_lsn, replay_lsn) AS bytes_behind,
       replay_lag
FROM pg_stat_replication
WHERE client_addr << '10.1.%';  -- Exemplo de CIDR de eu-west

Quando usar isso: Residência regulatória, escalonamento de leitura regional ou promoção de recuperação de desastres quando a região primária for perdida.

Exemplo de Trabalho

Implante uma réplica física entre regiões com slot e SLO de atraso:

# eu-west: backup base da primária us-east
pg_basebackup -h primary.us-east.db.internal -U replicator \
  -D /var/lib/postgresql/18/main -Fp -Xs -P -R \
  -C -S eu_west_dr_slot

-- primary_conninfo em eu-west inclui sslmode=verify-full
-- Consulta de alerta de atraso (executada na primária)
SELECT application_name,
       pg_wal_lsn_diff(pg_current_wal_lsn(), replay_lsn) AS dr_lag_bytes
FROM pg_stat_replication
WHERE application_name = 'eu_west_dr';

# Opcional: eu-west serve relatórios somente leitura via frontend de réplica HAProxy
# As escritas ainda são roteadas apenas para us-east até a declaração de DR

O que isso demonstra:

• O link entre regiões adiciona RTT da WAN ao atraso de replay.
• O slot físico na primária retém o WAL para a réplica de DR durante interrupções.
• A réplica de DR é somente leitura até que o manual de promoção seja executado.

Mergulho Profundo

Orçamento de Atraso

Defina o RPO de nível 1 entre regiões para o atraso p99 medido mais fallback de arquivo.

Esboço do Manual de Promoção

1. Declare o desastre (veja Manual de DR e Comunicações)
2. Pare as escritas na região primária (se parcialmente ativa)
3. Verifique se o atraso da réplica de DR é aceitável ou aceite a janela de perda de dados
4. pg_ctl promote na DR ou failover do Patroni no escopo da DR
5. Reposicione DNS / HAProxy / PgBouncer para a região de DR
6. Reconstrua a replicação de volta para a região primária quando recuperada

Entre Regiões em Cascata

Um hub em us-east alimenta várias regiões (veja Réplicas em Cascata) para reduzir o fan-out primário.

Armadilhas

• Tratar a réplica de DR como HA - Partição de rede WAN causa grande atraso; não é failover de sub-minuto. Correção: Patroni na mesma região para HA; entre regiões para DR.
• Replicação síncrona entre regiões - Latência de commit inaceitável para a maioria dos aplicativos. Correção: Assíncrona com RPO documentado.
• Sem slot na réplica de DR - Breve interrupção de rede na região perde WAL para sempre. Correção: eu_west_dr_slot permanente.
• Leituras em réplica de DR desatualizada - Usuários veem dados antigos. Correção: Roteie apenas análises para DR; documente o atraso na UI, se necessário.
• Promoção sem etcd na DR - Estado do Patroni confuso. Correção: Escopo DCS separado por região ou manual de promoção manual.

Alternativas

FAQs

Relacionados

• Noções Básicas de DR - Tiers de RPO/RTO
• Noções Básicas de Replicação de Streaming - configuração de standby
• Réplicas em Cascata - hub-spoke
• PITR na Nuvem - backup gerenciado entre regiões

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+.