Corruption 방지 + 감지

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

SQLite는 지구상에서 가장 많이 테스트된 소프트웨어 축에 들어. corruption은 거의 언제나 엔진 바깥에서 와. 단골 원인은 이래.

NFS, SMB, FUSE — 파일 locking이 깨져 있어. 네트워크 storage에 writer를 두면 절대 안 돼.
WAL 없이 쓰는 도중에 프로세스가 죽는 것 — WAL 이전 journal 모드는 강제 종료에 깨질 수 있어. WAL이면 깔끔하게 복구돼.
두 프로세스가 서로 다른 경로로 같은 파일을 여는 것 — symlink나 bind mount가 범인이야.
하드웨어 — 맛이 간 디스크, 맛이 간 RAM, 아직 안 썼는데 다 썼다고 대답하는 SSD.
writer가 도는데 백업을 덮어쓰는 것 — 쓰이는 중인 DB를 반쯤 덮어써버리는 거야.

알아채는 방법은 PRAGMA integrity_check야. 전체를 훑으니까 큰 DB에서는 느려. 빠른 대신 보장이 약한 PRAGMA quick_check도 있고. 백업을 뜬 뒤마다 돌리고, 주기적으로도 걸어둬.

Self-reference: 피파가 SQLite와 JSONL을 같이 쓰는 디자인은 복구 범위를 묶어두려고 존재해. SQLite가 손상되면 영향받은 conversation row를 잘라내고 JSONL을 다시 재생하면 되거든. JSONL ground truth는 재해 복구 장치야. 단순한 audit log가 아니지.

#!/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

Exercise

SQLite의 'How To Corrupt' 문서를 끝까지 읽어. 네 환경에 해당하는 원인을 전부 추려내고 각각의 대응책을 적어. PRAGMA로 막을지, 배포 방식을 바꿀지, 모니터링으로 잡을지. 그다음 네 서비스 하나에 주기적인 PRAGMA integrity_check와 알림을 붙여.

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

Code

External links

Exercise

Progress

댓글 0