Skill de Simulação de Failover
Etapas de verificação de failover Patroni/RDS para clusters PostgreSQL 18.4 - fluxo de simulação estruturado para agentes e engenheiros de plantão provarem que a HA realmente funciona antes de um incidente.
Busque em todas as páginas da documentação
Etapas de verificação de failover Patroni/RDS para clusters PostgreSQL 18.4 - fluxo de simulação estruturado para agentes e engenheiros de plantão provarem que a HA realmente funciona antes de um incidente.
## Skill de Simulação de Failover - fases
1. Pré-verificação: topologia, lag, backups atuais
2. Linha de base: registrar primário, réplicas, endpoints de conexão
3. Failover: switchover controlado ou failover do provedor
4. Verificar: escritas no novo primário, aplicativos reconectados
5. Simulação de rollback: failback opcional para a topologia original
6. Documentar: minutos de RTO, problemas, diferenças no runbook# Pré-verificação do Patroni
patronictl -c /etc/patroni/patroni.yml list
psql -h haproxy.internal -c "SELECT inet_server_addr(), pg_is_in_recovery();"Quando invocar:
# 1. Verificar atraso de replicação
psql -c "SELECT application_name, state, sync_state,
pg_wal_lsn_diff(pg_current_wal_lsn(), replay_lsn) AS lag_bytes
FROM pg_stat_replication;"
# 2. Switchover para replica2
patronictl -c /etc/patroni/patroni.yml switchover --master replica1 --candidate replica2 --force
# 3. Verificar novo primário
psql -h haproxy.internal -c "SELECT pg_is_in_recovery();" # esperar f
psql -c "CREATE TABLE failover_drill_20260709 (id int); DROP TABLE failover_drill_20260709;"
# 4. Confirmar que o antigo primário voltou como réplica
patronictl list# Testar failover apenas da instância - NÃO em produção sem janela de alteração
aws rds reboot-db-instance \
--db-instance-identifier myapp-staging-failover-test \
--force-failover
# Observar eventos
aws rds describe-events --source-identifier myapp-staging-failover-test --duration 30-- Após a reconexão do aplicativo
SELECT now(), inet_server_addr();
INSERT INTO drill_log (note) VALUES ('escrita pós-failover OK');O que isso demonstra:
SELECT pg_is_in_recovery();
SELECT * FROM pg_stat_replication; -- no primário: réplicas conectadas
SELECT slot_name, active, restart_lsn FROM pg_replication_slots;- [ ] PgBouncer/pooler detecta mudança de backend (ou breve tempestade de reconexão aceitável)
- [ ] Pool de conexão do ORM recicla dentro do tempo limite configurado
- [ ] Rotas de análise somente leitura para o endpoint de réplica ainda são válidas
- [ ] Tarefas em segundo plano são retomadas sem reinicialização manual do pod| Métrica | Alvo |
|---|---|
| Detecção para promoção | < 60s Patroni, específico do provedor RDS |
| Pico de taxa de erro do aplicativo | < 30s no p99 |
| Atraso de replicação pós-simulação | < 16 MB sustentado |
| Alternativa | Usar Quando | Não Usar Quando |
|---|---|---|
| Exercício de simulação de mesa | Apenas revisão de comunicação/jurídica | Provar RTO técnico |
| Chaos kill -9 postgres | Testar recuperação de falha | Primeira simulação do trimestre |
| Confiança no SLA do provedor | Nível hobby | RTO/RPO contratual |
Simulação controlada anual em produção com comunicação aos stakeholders, ou confiar em simulações trimestrais em staging se o failover Multi-AZ de produção for gerenciado pelo provedor e o staging corresponder à família de parâmetros.
Não. As simulações de failover testam a topologia HA; Runbook de Simulação PITR testa a recuperação de dados.
Switchover é gracioso (planejado). Failover é perda de líder não planejada. Pratique ambos; a skill usa switchover em staging por padrão.
Versões de Stack: Esta página foi escrita para PostgreSQL 18.4, Patroni 4.x, RDS PostgreSQL 18 e PgBouncer 1.24+.
Revisado por Chris St. John·Última atualização: 16 de jul. de 2026