# 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?