测验：备份、迁移与回滚演练

서비스가 연결을 연 채 WAL 모드 DB 를 쓰고 있다. 본파일만 cp 한 사본의 integrity_check 가 ok 였다. 실측에서 무엇이 확인됐나?

• ok 이므로 커밋된 주문이 모두 들어 있다
• WAL 에만 있던 커밋이 빠졌는데도 integrity_check 는 ok 였다
• 사본을 여는 순간 WAL 이 없어 오류가 났다
• cp 가 잠금을 기다려 서비스의 쓰기가 멈췄다

.backup 사본과 VACUUM INTO 사본의 관계로 맞는 것은(실측)?

• 파일 sha256 은 다르지만 .sha3sum --schema 는 같다
• 둘 다 WAL 모드로 남아 파일이 바이트까지 같다
• VACUUM INTO 는 WAL 내용을 읽지 못해 행이 적다
• 내용 해시가 달라 둘 중 하나만 백업으로 쓸 수 있다

마이그레이션을 BEGIN; …; PRAGMA user_version=3; COMMIT; 으로 감싸 sqlite3 에 -bail 없이 넣었다. 세 번째 문장이 UNIQUE 위반이면?

• UNIQUE 위반은 트랜잭션 전체를 되돌리므로 흔적이 없다
• sqlite3 가 첫 오류에서 멈추므로 COMMIT 은 실행되지 않는다
• 앞의 두 문장이 남은 채 COMMIT 되고 user_version 도 3 이 된다
• BEGIN 이 있으면 모든 오류가 치명적이라 파일이 잠긴다

강제 종료로 live.db-wal 이 남은 상태에서 백업을 cp 로 live.db 위에 덮었다. 실측에서 본 결과는?

• cp 가 -wal 을 함께 덮어써 깨끗하게 복원됐다
• SQLite 가 헤더 불일치를 감지해 남은 WAL 을 버렸다
• 파일이 손상돼 열리지 않았다
• user_version 은 백업 값인데 되돌렸어야 할 수정 행이 다시 보였다

user_version 을 마이그레이션 판 번호로 쓰는 근거로 맞는 것은?

• SQLite 가 스키마를 바꿀 때마다 자동으로 올려 준다
• 파일 머리 60번 오프셋의 애플리케이션용 정수이고 SQLite 자신은 쓰지 않는다
• sqlite_schema 테이블의 한 행이라 .sha3sum 에 포함된다
• WAL 모드에서만 저장되고 롤백 저널 모드에서는 사라진다

리허설 스크립트가 '실패해야 할 마이그레이션' 자리에 받은 파일이 성공해 버렸다. 올바른 처리는?

• 실패 주입이 실패하지 않았으니 리허설을 무효로 보고 0 이 아닌 값으로 끝낸다
• 마이그레이션이 성공했으니 복원을 건너뛰고 통과로 기록한다
• user_version 이 올라갔으니 백업을 새로 떠서 기준값을 갱신한다
• 성공 여부와 무관하게 복원만 되면 리허설은 통과다