RDS PostgreSQL: High Availability and Disaster Recovery

1. Por Que Alta Disponibilidade Importa

Imagine acordar às 3h da manhã com alertas de que seu banco de dados de produção está fora do ar. Seu e-commerce está offline. Cada minuto custa milhares de reais em receita perdida. Clientes estão frustrados. Seu time está em pânico.

É por isso que Alta Disponibilidade (HA) não é opcional para sistemas de produção.

2. Opções de Alta Disponibilidade no RDS

O RDS oferece três modelos de deployment, cada um com diferentes garantias de disponibilidade.

2.1. Single-AZ (Sem Standby) ❌

    ┌─────────────────┐
    │  Availability   │
    │    Zone A       │
    │                 │
    │  ┌───────────┐  │
    │  │ Primary   │  │
    │  │ Instance  │  │
    │  └───────────┘  │
    │                 │
    └─────────────────┘

    Sem redundância!

O que acontece se a primária falhar:

• RDS detecta a falha
• RDS provisiona nova instância EC2
• RDS anexa volumes EBS
• PostgreSQL inicializa
• Banco de dados fica disponível

⏰ Downtime: Tipicamente 10-30 minutos (às vezes mais)

Quando usar:

• Ambientes dev/test ✅
• Workloads não-críticos sensíveis a custo ✅
• Bancos que podem tolerar downtime prolongado ✅

⚠️ Riscos do Single-AZ

• Falha de hardware → 10-30 min de downtime
• Falha de AZ → Potencialmente horas de downtime
• Janelas de manutenção → Downtime durante upgrades
• Sem failover automático

Conclusão: Single-AZ NÃO é pronto para produção.

2.2. Multi-AZ com Um Standby (Síncrono) ✅

    ┌─────────────────┐        ┌─────────────────┐
    │   Availability  │        │   Availability  │
    │     Zone A      │        │      Zone B     │
    │                 │        │                 │
    │  ┌───────────┐  │        │  ┌───────────┐  │
    │  │ Primary   │  │◄──────►│  │ Standby   │  │
    │  │ Instance  │  │ Replic │  │ Instance  │  │
    │  └─────┬─────┘  │ Sínc   │  └───────────┘  │
    │        │        │        │                 │
    └────────┼────────┘        └─────────────────┘
             │
             │ Apps conectam aqui
             ▼
       DNS Endpoint
       mydb.abc.rds.amazonaws.com

Este é o setup padrão de produção para a maioria dos workloads.

Fluxo de Replicação Síncrona:

1. App envia: INSERT INTO users…
2. Primária recebe a escrita
3. Primária envia para standby: “Vou commitar isso”
4. Standby reconhece: “Recebi, persistido”
5. Primária faz commit
6. Primária responde para app: “Sucesso!”

Escrita só confirmada após standby reconhecer Benefícios:

• Zero perda de dados (RPO = 0)
• Failover rápido (RTO = 1-2 min)
• Automático (sem intervenção manual)
• Mesmo endpoint (mudança de DNS, sem alterações no app)

2.2.1. Cenário de Failover 1: Instância primária falha

O que acontece:

• Primária trava
• Health check do RDS detecta falha
• RDS inicia failover
• DNS aponta para standby
• Standby promovida a primária
• Novas conexões aceitas ✅

⚠️ Downtime total: ~1-2 minutos

Sua aplicação vê:

• Conexões existentes: Dropadas (precisam reconectar)
• Novas conexões: Breve rejeição, depois sucesso
• Perda de dados: ZERO (tudo estava sincronizado)

RDS automaticamente:

• Promove standby a primária
• Atualiza DNS (sem mudança de IP para o app)
• Começa a reconstruir novo standby em background

2.2.2. Cenário 2: Instância standby falha

O que acontece:

• Impacto: NENHUM na sua aplicação

Ações do RDS:

1. Detecta falha do standby
2. Primária continua servindo tráfego normalmente
3. RDS provisiona novo standby em background
4. Sincronização resume automaticamente

2.2.3. Cenário 3: AZ inteira falha

O que acontece:

• Se AZ da Primária falha:
  • Standby em AZ diferente assume
  • Tempo de failover: ~1-2 minutos
  • Zero perda de dados
• Se AZ do Standby falha:
  • Primária não afetada
  • RDS reconstrói standby em AZ saudável
  • Zero impacto na aplicação

2.3. Multi-AZ DB Cluster (Semi-Síncrono) 🚀

    ┌──────────────┐   ┌──────────────┐   ┌──────────────┐
    │     AZ A     │   │     AZ B     │   │     AZ C     │
    │              │   │              │   │              │
    │ ┌──────────┐ │   │ ┌──────────┐ │   │ ┌──────────┐ │
    │ │ Primary  │ │   │ │ Readable │ │   │ │ Readable │ │
    │ │ Instance │◄├───┤►│ Standby  │ │   │ │ Standby  │ │
    │ │          │ │   │ │    #1    │ │   │ │    #2    │ │
    │ └────┬─────┘ │   │ └────┬─────┘ │   │ └────┬─────┘ │
    │      │NVMe   │   │      │NVMe   │   │      │NVMe   │
    │      │SSD    │   │      │SSD    │   │      │SSD    │
    └──────┼───────┘   └──────┼───────┘   └──────┼───────┘
           │                  │                  │
           ▼                  ▼                  ▼
      Write Endpoint     Reader Endpoint    Reader Endpoint

Esta é a opção premium para RTO ultra-baixo e escalabilidade de leitura integrada.

Replicação Semi-Síncrona:

1. App envia: INSERT INTO orders…
2. Primária recebe a escrita
3. Primária envia para AMBOS standbys
4. Primária aguarda QUALQUER UM dos standbys reconhecer
5. Primária faz commit (não espera pelos dois)
6. Primária responde ao app: “Sucesso!”
7. Apenas um standby precisa confirmar (mais rápido que sync total)

Diferenças-chave do Multi-AZ com Um Standby:

• 2 standbys em vez de 1 (três AZs no total)
• Standbys são legíveis (podem servir queries SELECT)
• Failover mais rápido (<35 segundos vs 1-2 minutos)
• SSDs NVMe locais (melhor performance de I/O)
• Reader endpoint (balanceamento automático)

Quando Usar Multi-AZ Cluster:

• RTO < 35 segundos necessário
• Aplicações mission-critical
• Serviços financeiros, saúde
• E-commerce durante picos sazonais
• Workload pesado em leitura

3. Estratégias de Recuperação de Desastres

Alta Disponibilidade protege contra falhas de infraestrutura. Recuperação de Desastres protege contra eventos catastróficos: quedas em toda região, deleções acidentais, corrupção de dados, ransomware.

3.1. Snapshots do RDS

Snapshots são backups point-in-time do seu banco de dados inteiro.

Dia 1:
├─ 00:00 - Snapshot completo tirado
└─ Durante o dia: Logs transacionais capturados

Dia 2:
├─ 00:00 - Snapshot incremental (apenas mudanças)
└─ Durante o dia: Logs transacionais capturados

Dia 3:
├─ 00:00 - Snapshot incremental
└─ E assim por diante...

Snapshots Automatizados:
├─ Acontecem automaticamente diariamente
├─ Deletados após período de retenção
├─ Suportam restore point-in-time
└─ Vinculados à instância

Snapshots Manuais:
├─ Você os dispara
├─ NUNCA deletados automaticamente
├─ SEM restore point-in-time (apenas o momento do snapshot)
└─ Independentes da instância (persistem após deleção)

3.1.1. Processo de Restore de Snapshot

Timeline:

1. Iniciar restore (chamada API): 1 minuto
2. RDS provisiona nova instância: 5-10 minutos
3. Restore dados do snapshot: 10-60 minutos (depende do tamanho)
4. Instância fica disponível: Total 15-70 minutos

Fatores que afetam o tempo:

• Tamanho do banco (maior = mais longo)
• Classe da instância (maior = restore mais rápido)
• Carga da região (horários de pico podem ser mais lentos)

Após restore -> Nova instância:

• Endpoint diferente (precisa atualizar connection strings)
• Mesmos dados do momento do snapshot
• Mesma configuração (classe de instância, parâmetros)
• Instância original ainda rodando (você escolhe qual manter)

3.2. Read Replicas para DR

Read replicas servem a DOIS propósitos:

• Escalabilidade de leitura (descarregar queries SELECT)
• Recuperação de desastres (pode ser promovida a standalone)

  ┌─────────────────┐        ┌─────────────────┐
  │  us-east-1      │        │  us-west-2      │
  │                 │        │                 │
  │  ┌───────────┐  │        │  ┌───────────┐  │
  │  │ Primary   │  │───────►│  │  Read     │  │
  │  │ (Source)  │  │ Async  │  │  Replica  │  │
  │  └─────┬─────┘  │ Replic │  └───────────┘  │
  │        │        │        │                 │
  └────────┼────────┘        └─────────────────┘
           │
    Tráfego de escrita          

Replicação Assíncrona:

1. App escreve na primária
2. Primária faz commit imediatamente
3. Primária envia mudança para réplica
4. Réplica aplica mudança (eventualmente)
5. Réplica pode estar atrasada em relação à primária (segundos a minutos) ⚠️

Características-chave:

• Replicação async (sem impacto na latência de escrita)
• Pode estar na mesma região ou cross-region
• Pode ter classe de instância diferente da primária
• Pode ser promovida a instância standalone
• Lag de replicação possível (monitore de perto)

3.2.1. Read Replicas In-Region vs Cross-Region

Quando usar cross-region:

• Recuperação de desastres (proteção contra falha em toda região)
• Compliance (requisitos de residência de dados)
• Aplicação global (servir usuários da região mais próxima)
• Menor latência de leitura para usuários geograficamente distribuídos

3.2.2. Dimensionamento de Read Replica

Réplica pode ser de tamanho diferente da primária

Benefícios replica maior:

• Lida com workload pesado de leitura facilmente
• Sem degradação de performance
• Bom para queries analíticas

Risco replica menor:

• Réplica não consegue acompanhar primária
• Lag de replicação aumenta
• Eventualmente réplica fica muito atrasada
• Ruim para recuperação de desastres!

Regra prática: Réplica deve ser ≥ mesma classe que primária para propósitos de DR.

4. Alta Disponibilidade vs Recuperação de Desastres

5. Conclusão

Alta Disponibilidade e Recuperação de Desastres não são opcionais para bancos de dados de produção—são seguro essencial contra falhas inevitáveis.

8.1. Principais Conclusões Alta Disponibilidade:

• Use Multi-AZ para toda produção (RTO: 1-2 min, RPO: 0) ✅
• Use Multi-AZ Cluster para mission-critical (RTO: <35 seg) 🚀
• Nunca use Single-AZ para produção ❌

Recuperação de Desastres:

• Habilite backups automatizados (retenção de 35 dias) ✅
• Tire snapshots manuais antes de mudanças maiores ✅
• Use read replica cross-region para sistemas críticos ✅
• Teste DR trimestralmente (restore, promova, meça) ✅

Design de Aplicação:

• Lógica de retry para conexões ✅
• Transações idempotentes ✅
• Health checks e monitoramento ✅

Custos:

• Multi-AZ: ~2x custo Single-AZ (~R$ 1.500/mês para setup típico)
• ROI: Se paga prevenindo <1 hora downtime/mês

Métricas Críticas:

• Monitore: DatabaseConnections, ReplicaLag, FreeStorageSpace
• Alerte: Lag >60s, Storage <10 GB, Conexões >80%