PostgreSQL로 데이터베이스 스냅 샷을 빠르게 생성 / 복원 할 수 있습니까?

우선, 저는 DBA 나 sysadmin이 아닌 개발자입니다. 부드럽게 해주세요 :)

단일 사용자 작업으로 데이터베이스에서 복잡한 변경 사항을 트리거하는 응용 프로그램 워크 플로를 작업 중입니다. 일부 테이블에는 수백 개의 레코드를 만들고 다른 테이블에는 수백 개의 레코드를 업데이트하는 것 등이 있습니다. )에이 작업이 수행됩니다. 복잡성으로 인해 다른 테스트를 실행하기 전에 모든 변경 사항을 수동으로 되 돌리는 것은 매우 어렵습니다. 대부분의 개발 시간 동안 워크 플로 끝에 거의 "ROLLBACK"문을 삽입 할 수 있지만 변경 내용을 커밋 할 때 실제 테스트해야합니다.

작업 할 프로덕션 데이터베이스의 로컬 사본이 있습니다. 필자의 경우 모든 변경 사항을 취소하기 위해 스크립트를 작성하는 것보다 테스트 간 덤프 및 복원이 더 빠릅니다. 더 빠르지 만 여전히 속도가 느려집니다 (노화 노트북에서 복원하는 데 약 20 분이 걸립니다). 데이터베이스의 현재 상태에 대한 스냅 샷을 저장 한 다음 신속하게 복원 할 수있는 방법이 있습니까?

시스템에서 유일한 사용자임을 보장하며 루트 액세스 권한이 있습니다. tar 및 gzip을 사용할 때 데이터베이스 덤프는 ~ 100MB입니다. PostgreSQL 버전은 8.3입니다.

유용한 아이디어에 미리 감사드립니다.

파일 시스템 수준 스냅 샷을 사용할 수 있지만, 이는 종종 성가 시며 특별한 파일 시스템이 필요하며, 특히 노후 노트북에서 항상 사용 가능한 것은 아닙니다. ;-)

기본 상태를 데이터베이스로 만든 다음 CREATE DATABASE ... TEMPLATE기능을 사용하여 테스트 실행을 위해 새 데이터베이스를 만듭니다 . 테스트 후에는 해당 데이터베이스를 버립니다. 그러면 속도 제한은 기본적으로 cp -R데이터베이스 디렉토리에 대한 시간 입니다. 그것은 파일 시스템 스냅 샷 마법없이 얻을 수있는 속도입니다.

Stellar을 사용하면 데이터베이스 의 git 과 같습니다 .

Stellar를 사용하면 데이터베이스 마이그레이션 작성, 브랜치 전환 또는 SQL 혼란 등 데이터베이스를 신속하게 복원 할 수 있습니다. PostgreSQL 및 MySQL (일부)이 지원됩니다.

데이터베이스가 Virtualbox 에서 실행되는 경우 몇 초 안에 데이터베이스 상태와 OS 자체의 스냅 샷을 쉽게 저장하고 스냅 샷을 복원 할 수 있습니다 ( 데이터베이스 나 OS에 실제로 많은 데이터 가 있는 경우 1-2 분 무료로 가상 머신에 할당 된 적은 메모리).

대부분의 경우 랩톱에서 사용할 수있는 리소스가 거의 없다는 것을 감안할 때 데이터베이스가 호스팅되는 가상 머신을 실행하려면 경량 Windows (Windows 서버보다)를 설치하는 것이 가장 좋습니다.

프로덕션 사이트에서는 MediaTemple 의 스냅 샷 백업을 사용하여 동일한 결과를 얻습니다 (하지만 백업 슬롯 당 20 $이며 웹 호스팅 서비스에 따라 다르므로 귀하에게 맞지 않을 수 있습니다).

아마 당신이 바라는 대답은 아니지만 LVM과 같은 더 낮은 수준의 스냅 샷을 고려 했습니까?

동일한 작업을 시도 할 때이 질문을 발견하고 postgresql 데이터 디렉토리에서 git을 사용했습니다. 변경 사항을 폐기하는 것은 다음과 같이 쉽습니다.

git reset --hard

실험 할 수있는 또 다른 옵션은 실제로 postgresql 데이터 디렉토리의 사본을 저장 한 다음 복원 할 때 사본으로 기존 디렉토리를 다시 작성하는 것입니다. 디스크에 더 많은 공간이 필요하지만 백업에서 복원하는 것보다 확실히 빠릅니다. 그래도 이것이 템플릿 방법보다 빠를 지 확실하지 않으므로 먼저 테스트를하는 것이 좋습니다.

나는 말을 할 필요가 있지만 Stellar및 git reset --hard흥미로운 솔루션입니다, 나는 더 큰 데이터베이스 및 테스트에 문제가있을 것이다, 그리고 내가 사용합니까 Virtualbox, 어떻게 지금, 더 큰 시험에서,이 때 당신을 좀 더 "문제"가하는 등 솔루션을 베어 메탈 등의 솔루션을 사용하고 있습니다.

따라서 ZFS@Peter Eisentraut가 언급 한 다음과 같은 이유로 향후 파일 시스템으로 고려할 파일 시스템을 언급했습니다.

1. 스냅 샷-특히 Prod에서 QA / DR로 복제 할 때 테스트에 동일한 "파일 시스템"을 사용할 수 있습니다.

#On a replication node, rather stop, snap, restore for a "consistent" backup ;)
su -l -c "/usr/bin/m2ee stop" acw_qa
pg_ctlcluster ${=QA} stop --force
zfs destroy -R $SNAPSHOT
pg_ctlcluster ${=REPLICATION} stop --force
zfs snapshot $SNAPSHOT
pg_ctlcluster ${=REPLICATION} start

zfs destroy $CLONE
zfs clone -o mountpoint=$CLONEDIR $SNAPSHOT $CLONE
rm $CLONEDIR/$CLUSTER/recovery.conf
pg_ctlcluster ${=QA} start
su -l -c "/usr/bin/m2ee start" acw_qa

1. 테스트하기 전에 테스트가 위와 같이 postgresql 중지를 수행하기 전에 zfs snapshot $SNAPSHOTpostgresql을 시작한 다음 롤백하고 postgresql을 중지하십시오.zfs rollback $SNAPSHOT

2. 압축-Postgresql은 데이터베이스에서 일반적인 3 : 1 압축을 얻으므로 많은 테스트를 더 많이 수행 할 수 있습니다.)