파일이 곧 DB 야

파일 하나, 2004 년 이후 byte 안정성

SQLite DB 는 잘 정의된, stable 한, cross-platform binary format 의 파일 하나야. 포맷이 3.0.0 (2004) 이후로 stable 하고 SQLite 팀은 최소 2050 년까지 호환성 유지하기로 약속했어. macOS 에서 만든 파일이 Windows, Linux, Raspberry Pi, Android 폰에서 byte 단위로 똑같이 열려.

흔한 확장자는 .db, .sqlite, .sqlite3 — 근데 아무 거나 써도 돼. SQLite 는 파일명 신경 안 써, 파일 헤더 보고 자기 자신을 식별해.

WAL (Write-Ahead Logging) 모드를 켜면 — 동시 워크로드면 거의 항상 켜야 됨 — DB 옆에 파일 두 개가 더 보여:

myapp.db-wal — Write-Ahead Log, 아직 main file 로 checkpoint 안 된 최근 변경 사항.
myapp.db-shm — 동시 reader 들 조율용 shared memory 파일.

이 파일들은 SQLite 가 자동으로 관리해. 마지막 connection 이 깔끔하게 닫히면 보통 사라져. WAL 모드 DB 백업할 때는 세 파일 다 같이 복사하거나, 공식 .backup 명령 (consistent snapshot 만들어 줌) 을 써.

Warning: WAL 모드 DB 를 writer 활성화 상태에서 그냥 cp 하면 corrupt copy 가 나올 수 있어. sqlite3 source.db ".backup target.db" 나 C-level sqlite3_backup API 써. cron + cp 는 '내 백업이 2 년 동안 silently corrupt 였더라' 류 사고의 단골 원인이야.

Code

디스크 위에 뭐가 있나·bash

ls -la myapp.db*
# -rw-r--r--  myapp.db       28672 bytes  (DB)
# -rw-r--r--  myapp.db-wal   45280 bytes  (최근 변경, WAL 모드)
# -rw-r--r--  myapp.db-shm   32768 bytes  (WAL 용 shared-memory index)

# 파일 헤더 확인 — magic string 이 'SQLite format 3\0' 야
head -c 16 myapp.db | xxd
# 00000000: 5351 4c69 7465 2066 6f72 6d61 7420 3300
#           S Q L i t e   f o r m a t   3 .

.backup 으로 안전 백업·bash

# Online backup — writer 활성 상태에서도 됨
sqlite3 myapp.db ".backup nightly-$(date -I).db"

# Python 에서 동일 — C-level sqlite3_backup API 사용
python3 -c "
import sqlite3, datetime
src = sqlite3.connect('myapp.db')
dst = sqlite3.connect(f'nightly-{datetime.date.today()}.db')
src.backup(dst)
src.close(); dst.close()
"

Exercise

작은 SQLite DB 만들고 몇 row 넣은 다음 WAL 모드로 바꿔봐 (PRAGMA journal_mode=WAL;). Python 루프로 계속 row 추가하면서 백업 세 가지 시도: (1) raw cp, (2) sqlite3 .backup, (3) Python 에서 sqlite3_backup. 각 백업 열어서 row count 와 integrity 매치되는지 확인. 어떤 게 일관된 snapshot 만들었고 어떤 게 못 했는지 기록.

파일 하나, 2004 년 이후 byte 안정성

Code

External links

Exercise

Progress

댓글 0