CRASH-SST-001: SSTable truncado é detectado mas sem recuperação automática — perda de dados

[ElioNeto]

🟠 Alto | Resiliência | SSTable

Problema

Se um SSTable for truncado (crash durante escrita, setor defeituoso), o engine detecta o problema (magic number inválido ou CRC32 mismatch) mas descarta o arquivo inteiro sem tentar recuperar registros parciais de blocos íntegros adjacentes.

Impacto

Dados são perdidos mesmo quando a maioria dos blocos no arquivo está íntegra. O Scrubber identifica o problema mas não tem auto-repair.

Evidência

src/storage/reader.rs:60-80: validação de magic number e tamanho mínimo → retorna CorruptedData
src/infra/scrubber.rs:290-300: CRC32 mismatch detectado mas sem ação corretiva

Cenário de falha

1. Crash durante escrita do SSTable (últimos 2 blocos não escritos)
2. No startup, engine detecta CRC32 mismatch nos últimos 2 blocos
3. Engine descarta o arquivo inteiro — inclusive os primeiros 8 blocos que estavam íntegros
4. Perda de dados evitável

Correção recomendada

// Algoritmo de auto-repair parcial:
// 1. Identificar blocos com CRC32 válido
// 2. Copiar blocos válidos para novo arquivo SSTable
// 3. Reconstruir metadados (bloom filter, index) para blocos válidos
// 4. Mover arquivo corrompido para diretório de quarentena
// 5. Adicionar novo SSTable (parcial) ao VersionSet
// 6. Log de alerta com detalhes

Implementar como função em src/infra/scrubber.rs:

pub fn try_repair_sstable(path: &Path) -> Result<Option<PathBuf>>;

Esforço: Alto (16h)