2.9 KiB
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 seroffse 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_adjno 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 arquivopostmaster.pid(PG) oumysql.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:
- Não tente consertar a produção corrompida.
- Suba uma nova instância (VM limpa).
- Importe o Último Dump/Backup (Nível 1).
- 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?