here의 예제 2 코드를 사용하여 유휴 데이터베이스의 온라인 백업을하고 있습니다. 두 데이터베이스의 .dump은 동일하지만 백업 파일은 원본과 동일하지 않습니다 (길이는 같지만 3 바이트가 다릅니다). 다른 시간에 찍은 백업 파일은 서로 동일합니다.sqlite : 온라인 백업이 원본과 동일하지 않습니다
백업이 원본과 동일하다는 간단한 보증을하고 실제 데이터베이스와 백업에 체크섬을 기록하여 복원을 단순화하고 싶습니다. 내가이 문제를 해결할 수 있는지 또는 백업 API를 사용하여 동일하게 비교되는 파일을 생성 할 수 있는지 생각해보십시오.
온라인 백업은 기존 데이터베이스에 쓸 수 있으므로이 쓰기는 트랜잭션 내에서 수행됩니다. 이러한 트랜잭션이 끝나면 파일 변경 카운터 (오프셋 24-27)가 변경되어 다른 프로세스가 데이터베이스가 수정되었음을 감지하고 해당 프로세스의 모든 캐시가 유효하지 않음을 감지 할 수 있습니다. 이 변경 카운터는 대상 데이터베이스의 이전 값과 같을 수 있으므로 원래 데이터베이스의 값을 사용하지 않습니다.
대상 데이터베이스를 새로 만들면 변경 카운터가 0에서 시작됩니다. 이것은 원래 데이터베이스의 변경 사항 일 가능성이 있지만 적어도 일관성이 있습니다.
데이터베이스에 사용되지 않은 페이지가 있으므로 오프셋 28의 바이트가 감소했습니다. 데이터베이스가 실제로 새 스키마 기능을 사용하지 않기 때문에 오프셋 44의 바이트가 변경되었습니다. 백업 전에 VACUUM을 수행하면 이러한 변경 사항을 피할 수 있지만 변경 카운터에는 도움이되지 않을 수 있습니다.
감사. 이 때문에 (a) 수동 복사본을 사용하여 데이터베이스를 백업하는 것이 좋지 않을 것 같고 (b) 백업 API에 변경 카운터 등을 변경하지 않는 옵션이 있어야한다고 생각합니다. – EML
백업 API는 파일 대 파일이 아닌 데이터베이스 대 데이터베이스로 작동합니다. [BEGIN EXCLUSIVE] (http://www.sqlite.org/lang_transaction.html)로 파일을 잠그면 파일을 복사 할 수 있습니다. –
백업 API가 모든 백업의 일관성을 유지하기 때문에 (즉, 진행중인 트랜잭션은 무시됩니다) 동일하다고 예상하지 않았을 것입니다.
글쎄, 그래,하지만 데이터베이스가 유휴 상태라고 했어. – EML
나는 파일들이 정확히 동일하다는 것을 보장 할 방법이 없다고 생각합니다. 데이터베이스 파일이 다르다고해서 다른 내용을 가지고있는 것은 아닙니다. 하나는 다른 페이지보다 더 많은 자유 페이지를 가질 수 있고, 페이지 순서가 변경 될 수 있습니다. –
어떤 바이트입니까? 오프셋 24? –
바이트 27, 28 및 44는 원본에서 22, 154 및 4이고 0, 1 및 1 (모두 10 진수)으로 끝납니다. – EML