기술 · 실용 가이드
Python SQLite 백업이 멈췄나요? 커밋 전에 두 연결을 확인하세요
원본의 미확정 쓰기, 사용 중인 대상 연결, 외부 잠금 경합을 구분하세요. 트랜잭션 플래그만으로 해결책을 정할 수는 없습니다.
Python SQLite 백업은 익숙한 데이터베이스 잠금 예외 없이 계속 재시도할 수 있습니다. commit()을 추가하면 어떤 예제는 해결되지만, 백업 보조 함수가 결정할 권한이 없는 업무 변경까지 확정할 수 있습니다. 먼저 원본, 대상, 끝나지 않은 작업을 식별하세요.
작은 대조 시험 12개로 복사 정체, 대상의 즉각적인 거부, 성공하는 읽기 트랜잭션을 구분했습니다. in_transaction=True는 조사할 단서이지, 커밋하라는 지시나 모든 백업을 거부할 이유가 아닙니다.
1. 상태 변경 전에 두 연결의 역할을 기록하세요
Python과 sqlite3.sqlite_version, 실제 호출, 양쪽 데이터베이스 경로, 각 연결의 autocommit, isolation_level, in_transaction을 기록합니다. 마지막 SQL과 트랜잭션 책임자도 확인합니다. 대상에는 이름이 고유한 별도 후보 파일을 쓰세요. 운영 중인 원본이나 보존해야 할 기존 백업을 대상으로 지정하지 마세요.
첫 진행 콜백 전 실패인지, 반복 호출 후에도 끝나지 않는지 구분합니다. 상태, 남은 페이지 수, 전체 페이지 수를 함께 기록하세요. SQLite는 백업 중 대상 연결 사용을 제한하므로 그 연결로 쿼리하지 않습니다. busy 상태라면 남은 페이지가 0이어도 완료 증거가 아닙니다.
2. 불리언 값을 진단으로 단정하지 마세요
Linux의 CPython 3.12.14와 SQLite 3.53.1에서 원본의 미커밋 INSERT는 상태 5인 SQLITE_BUSY를 반복했습니다. 진단 콜백으로 세 번 뒤 중단했습니다. 시험의 트랜잭션 책임자가 의도적으로 커밋한 뒤에는 같은 원본에서 성공했습니다. 다른 연결의 배타적 잠금도 상태 5였으므로 숫자만으로 책임자를 알 수 없었습니다.
autocommit=False일 때 빈 지연 트랜잭션과 테이블을 읽은 원본 트랜잭션 모두 in_transaction=True인 채 성공했습니다. 같은 모드의 새 대상도 읽기 전에는 성공했습니다. 하지만 SELECT 후 다시 백업하자 진행 콜백 없이 “destination database is in use”로 실패했습니다. 미확정 쓰기가 있는 대상도 거부되었습니다. 플래그보다 연결의 역할과 실제 작업이 중요합니다.
3. 어떤 데이터를 포함할지 결정하세요
원본의 미확정 쓰기를 포함해야 한다면 애플리케이션의 트랜잭션 책임자가 의도한 작업 단위를 끝낸 뒤 재시도하게 합니다. 증상을 없애려고 범용 보조 함수에서 커밋하지 마세요. Python 문서상 autocommit=True로 바꾸면 대기 중인 트랜잭션을 커밋합니다. 기존 업무 연결의 속성 변경은 실제 데이터에 관한 결정입니다.
파일 데이터베이스라면 전용 읽기 전용 연결로 작성자를 커밋하지 않고 확정 데이터만 복사할 수 있습니다. 별도 읽기 대조에서는 작성자에게 미확정 행 2가 보이는 동안 백업에는 행 1만 담겼습니다. 행 2를 의도적으로 제외한 성공입니다. 단순한 :memory:의 새 연결은 다른 데이터베이스이므로 메모리 원본에 그대로 적용할 수 없습니다.
4. 백업 콜백에서 재시도를 제한하세요
시험한 CPython 구현은 SQLITE_OK, SQLITE_BUSY, SQLITE_LOCKED에서 반복합니다. 백업 진행 콜백은 각 단계 뒤 실행되며 콜백 예외는 작업을 정리하고 중단합니다. 연결의 잠금 timeout은 백업 전체의 마감 시간이 아닙니다. 별도의 SQL 실행 진행 처리기와 혼동하지 말고 backup(progress=...)를 사용하세요.
전체 경과 시간을 제한하려면 호출 전에 time.monotonic()으로 마감 시각을 정합니다. 콜백에서 인자 세 개를 기록하고, 마감이 지났으며 상태가 SQLITE_DONE이 아니면 TimeoutError를 발생시킵니다. 진행하다 다시 시작하는 작업도 제한하려면 마감을 갱신하지 않습니다. 연결 timeout은 0, 콜백 예산은 0.03초인 잠금 대조에서 약 0.03초 뒤 예외가 났습니다. 단계 사이의 협력적 검사이며, 멈춘 시스템 호출에 대한 엄격한 실시간 보장은 아닙니다.
5. 중단과 백업 승인을 구분하세요
거부나 콜백 예외 뒤에는 전용 연결을 닫고 후보를 사용 가능한 백업 집합에서 제외합니다. 파일 존재, 콜백 실행, 예외 처리만으로 승격하지 마세요. 호출 성공 후에는 대상을 닫고 그 후보를 다시 열어 무결성과 필요한 업무 데이터를 확인합니다. 연결한 승인 가이드에서 이 후속 단계를 다룹니다.
시험은 작은 로컬 파일 및 메모리 데이터베이스와 롤백 저널에 한정했습니다. WAL의 지속 쓰기, 네트워크 파일시스템, ORM, 모든 Python 릴리스는 시험하지 않았습니다. 독립적인 Hermes 보고는 연속 busy 재시도를 제한하는 2026년 8월 16일 수정 병합으로 이어졌습니다. 그 애플리케이션의 정책은 보편적인 전체 마감 시간이 아닙니다. 원본을 보존하고 완료 정책을 정한 뒤 다음 시도를 계획하세요.
