69 lines
2.9 KiB
Markdown
69 lines
2.9 KiB
Markdown
# 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?
|