manuais-e-documentacao-itguys/documentacao bancos de dados/Nivel_3_[Nível 3] Arquitetu...

2.9 KiB

MANUAL TÉCNICO - ARQUITETURA DE PERSISTÊNCIA E TROUBLESHOOTING AVANÇADO

Código: ITGENG 0021/26 | Classificação: CONFIDENCIAL Responsável: João Pedro Toledo Gonçalves | Data: {{DATA_ATUAL}}

1. HISTÓRICO DE REVISÃO

Data Versão Descrição Autor
{{DATA_ATUAL}} 1.0 Criação Inicial João Pedro Toledo Gonçalves

2. OBJETIVO

Definir políticas de persistência de dados (Trade-off Performance vs Segurança) e procedimentos de recuperação de desastres (Crash Recovery e OOM).


3. ESTRATÉGIAS DE PERSISTÊNCIA REDIS

O Redis pode ser apenas Cache (volátil) ou Banco (persistente).

Modo Descrição Prós Contras
RDB (Snapshot) Salva o banco a cada X minutos. Rápido restore, arquivo compacto. Perde os dados desde o último snap.
AOF (Append Only) Salva cada comando escrito. Perda mínima (1s), Seguro. Arquivo cresce muito, restore lento.
Híbrido RDB + AOF. Segurança do AOF + Rapidez do RDB. Mais I/O de disco.

Recomendação iT Guys: Use Híbrido para bancos críticos e Apenas RDB para Cache.


4. PERSISTÊNCIA SQL (WAL / BINLOG)

Se o servidor desligar da tomada, os dados no WAL/Binlog salvam o dia.

PostgreSQL (WAL):

  • fsync = on: OBRIGATÓRIO. Garante que o dado foi pro disco físico. Desativar dá velocidade mas corrompe o banco em crash.
  • synchronous_commit: Pode ser off se você aceita perder alguns milissegundos em troca de performance.

5. CENÁRIOS DE CRASH E SOLUÇÕES

Cenário 1: OOM Killer (Out Of Memory)

O Linux mata o banco porque acabou a RAM.

  • Sintoma: Log do sistema diz Killed process 1234 (postgres).
  • Correção Imediata: Aumente o Swap ou reduza os Buffers do banco.
  • Prevenção: Ajuste o oom_score_adj no Systemd para -1000 (Imune) - Use com cautela extrema.

Cenário 2: Arquivo Corrompido (.pid lock)

Após um crash elétrico, o serviço não sobe dizendo que "já está rodando".

  • Solução: Verifique se o processo existe (ps aux). Se não existir, delete o arquivo postmaster.pid (PG) ou mysql.pid.

Cenário 3: Redis em modo Read-Only

O Redis parou de aceitar escrita.

  • Causa provável: O disco encheu ou o RDB falhou (stop-writes-on-bgsave-error yes).
  • Solução: Libere espaço em disco ou corrija a permissão da pasta de dados.

6. POLÍTICA DE DISASTER RECOVERY (DR)

Em caso de corrupção total:

  1. Não tente consertar a produção corrompida.
  2. Suba uma nova instância (VM limpa).
  3. Importe o Último Dump/Backup (Nível 1).
  4. Reaplique os logs de transação (Point-in-Time Recovery) se disponíveis (Requer setup prévio de Archiving).

7. VALIDAÇÃO FINAL

  • A persistência (fsync/AOF) está ativa conforme a criticidade?
  • O servidor tem Swap configurado para segurar picos antes do OOM?