Corruption 방지 + 감지

SQLite 는 정확하게 쓰면 엄청 안정적

SQLite 가 지구상에서 가장 많이 테스트된 소프트웨어 중 하나. Corruption 거의 항상 엔진 밖에서 옴. 정통 원인:

NFS/SMB/FUSE — 파일 locking 깨짐. 네트워크 storage + writer 절대 X.
WAL 없이 write 도중 kill — pre-WAL journal mode 가 hard kill 에 corrupt 가능. WAL 이 깨끗 recovery.
두 프로세스가 다른 path 통해 같은 파일 open — symlink, bind mount.
Hardware — 나쁜 디스크, 나쁜 RAM, 영속 전 write ack 하는 거짓말 SSD.
Writer 활성 동안 백업 restore — in-use DB 의 partial overwrite.

Corruption 감지 = PRAGMA integrity_check (full scan; 큰 DB 느림) 또는 PRAGMA quick_check (빠름, weaker 보장). 모든 백업 후 + schedule.

Self-reference: 피파의 SQLite + JSONL 디자인이 일부 corruption recovery 가 bounded 라서 존재 — SQLite 가 손상 보이면 영향 받은 conversation row purge + JSONL replay. JSONL ground truth 가 disaster-recovery 메커니즘, audit log 만 X.

#!/bin/bash DB=/var/lib/myapp/myapp.db result=$(sqlite3 "$DB" 'PRAGMA integrity_check') if [ "$result" != "ok" ]; then echo "Corruption detected: $result" | mail -s 'SQLite corruption' admin@example.com exit 1 fi

Corruption 방지 + 감지

SQLite 는 정확하게 쓰면 엄청 안정적

Code

External links

Exercise

Progress

댓글 0