Como configurar failover automático entre duas VPS Debian com PostgreSQL replicação e evitar split‑brain

Por · Publicado em · 8 min de leitura

Pirâmide desenhada com giz num quadro‑negro, com os números 3, 2 e 1 em cada nível
Ilustração conceitual 3/2/1, adequada para explicar quórum e arquitetura de alta disponibilidade Foto: athree23 / Pixabay

Quer aprender como configurar failover automático entre duas VPS Debian com PostgreSQL replicação e evitar split‑brain? O desafio real está em ter quórum para promover, checks confiáveis e um ponto de entrada estável (VIP/DNS). Veja uma arquitetura prática com witness, parâmetros críticos de replicação, scripts de healthcheck e um playbook de incidentes para reduzir riscos e tempo de recuperação.

O problema real: duas VPS, partições de rede e risco de split‑brain

Com apenas dois nós, qualquer perda de conectividade pode fazer cada lado acreditar que é o primário. Sem quórum, ocorre split‑brain e corrupção lógica de dados.

Para ter failover automático confiável, combine detecção de falha, coordenação com consenso (ou testemunha) e um mecanismo de mudar o ponto de entrada (VIP/DNS). Sem isso, automação vira roleta.

  • Detecção: healthchecks que validam primário e capacidade de escrita.
  • Coordenação: witness/DCS para desempatar decisões de promoção.
  • Mudança de tráfego: VIP com Keepalived/VRRP ou DNS com TTL baixo.

Arquitetura segura recomendada (2 nós + witness + VIP)

Use duas VPS Debian (primário e standby) e um elemento leve como witness ou um serviço de consenso (DCS) — por exemplo, etcd/Consul quando usado por uma ferramenta de HA. O VIP fica no primário saudável e acompanha o failover.

Crie um túnel privado entre as VPS para replicação e saúde. Isso reduz exposição e ajuda a latência. Se precisar, siga este passo a passo de túnel site‑to‑site com WireGuard: como configurar WireGuard site-to-site.

Implemente fencing lógico: se o primário perder contato com o witness, deve abdicar do VIP e recusar escritas. Esse guard‑rail diminui drasticamente o risco de split‑brain.

  • Primário: recebe escritas e anuncia o VIP.
  • Standby: replica e pode ser promovido automaticamente.
  • Witness/DCS: fornece quórum na promoção.
  • VIP via Keepalived/VRRP: ponto de entrada estável.
  • Canal privado: túnel WireGuard entre as VPS.

Replicação: escolhas e parâmetros essenciais no PostgreSQL

A replicação nativa por streaming resolve a maioria dos casos. Opte por síncrona (RPO≈0, mais latência) ou assíncrona (menor latência, risco mínimo de perda no failover).

Ajuste parâmetros para estabilidade e previsibilidade durante failover e rejoin. Quanto mais explícitos os limites de WAL e checkpoints, menor a surpresa em incidentes.

Sincronize credenciais e configs de modo controlado. Use migrations e um plano de rollback para evitar divergências entre nós durante mudanças estruturais.

  • synchronous_commit e synchronous_standby_names (quorum ou 1‑sync).
  • wal_keep_size e slots de replicação para evitar quedas.
  • primary_conninfo com SSL/TLS no link de replicação.
  • hot_standby=on para leituras no standby.
  • checkpoint_timeout e max_wal_size compatíveis ao volume.

Ferramentas de orquestração: compare antes de escolher

Automatizar o failover exige uma orquestração confiável. Avalie prioridades: simplicidade, recursos, integração com VIP/DNS e curva de operação. A escolha depende do time e do ambiente.

Opção Como funciona Vantagens Cuidados / Limitações Quando usar
Patroni + etcd/Consul Control plane com DCS, promoção e rejoin gerenciados Líder com lock; switchover/failover claros; hooks Precisa de DCS estável; demanda aprendizado operacional Ambientes que buscam HA madura e flexível
repmgr + witness Daemon monitora nós; witness desempata promoção Leve e integrado ao PostgreSQL Planeje witness e fencing com atenção Setups simples com dois nós + testemunha
pg_auto_failover Monitor coordena primário/standby e failover Fácil de iniciar; foco em HA nativa Menos flexível em cenários complexos Times pequenos que priorizam simplicidade
Keepalived + scripts VIP decide ativo via healthcheck customizado Controle fino sem DCS externo Você cria os guard‑rails anti split‑brain Ambientes mínimos com requisitos bem definidos

Healthcheck seguro do VIP: anuncie só com quórum

Um healthcheck frágil abre caminho ao split‑brain. O script abaixo só retorna sucesso se o nó for primário e conseguir falar com o witness/DCS. No Keepalived, use como vrrp_script. Nunca anuncie o VIP sem confirmar quórum.

Ajuste PG_URI, WITNESS_HOST/PORT e a exigência de síncronos conforme sua política de RPO e topologia.

#!/usr/bin/env bash
set -euo pipefail

PG_URI="${PG_URI:-postgresql://[email protected]/postgres}"
WITNESS_HOST="${WITNESS_HOST:-10.0.0.10}"
WITNESS_PORT="${WITNESS_PORT:-2380}"  # etcd (use 8300 p/ Consul)
REQUIRED_SYNC="${REQUIRED_SYNC:-0}"

# 1) É primário e gravável?
if ! psql "$PG_URI" -tAc "SELECT NOT pg_is_in_recovery();" | grep -qx "t"; then
  exit 1
fi

# 2) Consegue falar com o witness/DCS? Evita VIP em partição isolada
if ! timeout 1 bash -c ">/dev/tcp/$WITNESS_HOST/$WITNESS_PORT"; then
  exit 1
fi

# 3) (Opcional) Garante standby(s) síncrono(s) prontos se exigir RPO≈0
if [ "$REQUIRED_SYNC" -gt 0 ]; then
  READY=$(psql "$PG_URI" -tAc "SELECT count(*) FROM pg_stat_replication WHERE sync_state IN ('sync','quorum');")
  if [ "$READY" -lt "$REQUIRED_SYNC" ]; then
    exit 1
  fi
fi

exit 0

Playbook de incidentes: promoção, retorno e rejoin seguro

Defina um runbook curto e testado. Ao falhar o primário, a orquestração promove o standby e o VIP muda. Se houver suspeita de partição, force o antigo primário a recusar escritas e a soltar o VIP. Na volta, faça rejoin como réplica seguindo a timeline correta.

Mantenha backups consistentes para suportar PITR. Veja abordagens práticas em backups incrementais e criptografados em S3 e como executar um PITR sem downtime.

  • Falha detectada: VIP muda, standby é promovido automaticamente.
  • Partição: antigo primário sem VIP e sem escritas até confirmar quórum.
  • Retorno: rejoin do nó recuperado como standby na timeline vencedora.
  • Mudanças de schema: faça via migrations com janela e rollback.

Testes de DR: validar failover sem interromper o negócio

Teste em janela controlada. Valide troca do VIP, continuidade de escritas e consistência após switchover e failover simulado. Tire snapshot/backup antes do exercício. Audite o estado antes e depois e registre lições no runbook.

Reforce a postura de segurança do host para reduzir falsos positivos e falhas colaterais. Consulte o checklist de segurança para VPS Linux.

  • Crie/atualize uma tabela de teste antes do switchover.
  • Provoque switchover/failover com a ferramenta escolhida.
  • Confirme que o antigo primário virou standby e os dados persistem.
# No primário atual
psql -tAc "SELECT pg_is_in_recovery();"
psql -c "CREATE TABLE IF NOT EXISTS ha_test(id int primary key); INSERT INTO ha_test VALUES (1) ON CONFLICT DO NOTHING;"

# Execute o switchover/failover pela orquestração

# No novo primário
psql -tAc "SELECT pg_is_in_recovery(); SELECT count(*) FROM ha_test;"

Checklist anti split‑brain e tempos de failover

Concentre‑se nos tempos e nas condições de promoção. O checklist abaixo ajuda a reduzir riscos em duas VPS com witness. Revise periodicamente com base em incidentes e crescimento de carga. Timeouts curtos geram failover indevido; longos atrasam a recuperação.

  • Healthcheck do VIP só passa se: primário verdadeiro + witness acessível.
  • Timeouts coerentes: detecção (3–10s), promoção (10–30s), anúncio do VIP (≥ detecção).
  • Se usar síncrona: garanta pelo menos 1 standby pronto (quorum).
  • Evite restart em loop; use backoff exponencial nos serviços.
  • Monitore lag de replicação e reaplicação de WALs no standby.
  • Documente passos de rejoin e limpeza de timelines antigas.

Perguntas frequentes

Preciso de um terceiro nó para evitar split‑brain?

Em cenários com duas VPS, um terceiro elemento (witness ou DCS) é a forma mais segura de evitar split‑brain. Ele fornece quórum para decisões de promoção. Sem quórum, partições de rede podem criar dois primários simultâneos e corromper dados.

Posso ter RPO≈0 com apenas duas VPS?

Sim, usando replicação síncrona com um standby. Você reduz o risco de perda de dados, mas aumenta a latência de escrita e a sensibilidade a falhas de rede. Garanta healthchecks robustos e witness acessível antes de anunciar o VIP, senão a indisponibilidade pode crescer.

É melhor Patroni, repmgr ou scripts com Keepalived?

Depende da prioridade. Patroni oferece automação madura com DCS. repmgr é mais leve e funciona bem com witness. Keepalived com scripts dá controle fino, mas você deve criar guard‑rails anti split‑brain. Avalie experiência da equipe e complexidade do ambiente.

Como testar o failover com segurança?

Faça snapshot/backup, crie uma tabela de teste e force um switchover programado. Verifique a mudança do VIP, o estado de pg_is_in_recovery em ambos os nós e a persistência dos dados. Monitore lag e erros de log. Atualize seu runbook após o exercício.

O que fazer quando o antigo primário volta depois do failover?

Não promova automaticamente. Remova VIP e escrita, confirme a timeline vencedora e faça rejoin como standby. Ferramentas de HA possuem comandos de rejoin seguros; evite repoint manual sem validar a timeline para não arriscar divergência ou perda de dados.

Quer revisar seu failover PostgreSQL e playbooks?

Converse sobre seu cenário com duas VPS Debian. Avaliamos riscos de split‑brain, fortalecemos healthchecks/VIP e organizamos testes de DR com replicação consistente.

Falar sobre failover seguro

Veja também