우리는 많은 Linux VM을 vmware / shared 스토리지 환경에서 실행하고 있으며 각각은 자체 postgreSQL 인스턴스 (9.0과 9.3의 혼합)를 실행합니다. 현재 전체 VM은 단일 루트 파티션 / 볼륨에 있으며 백업 / 복원 프로세스 (및 DR 사이트로의 복제)를 위해 기본 VMFS 볼륨의 스토리지 기반 스냅 샷을 사용하여 큰 성공을 거두었습니다 (~ 8 년).
스토리지 아키텍처로 인해 postgres WAL 파일을 캐시되지 않은 대부분의 쓰기 볼륨으로 분리하여 스토리지 측에서 캐시 변동을 줄 이도록하는 것이 유리합니다. 스토리지 (Nimble Storage)를 사용하면 두 볼륨을 단일 보호 / 스냅 샷 그룹에 할당 할 수 있지만, 보호 그룹의 모든 볼륨에서 스냅 샷이 정확히 동시에 발생한다는 것을 공급 업체로부터 이끌어 낼 수 없었습니다. -가능할 것입니다. 그러나 항상 밀리 초가 떨어져있을 가능성이 있습니다.
이를 위해 pg_bench를 사용하여 가능한 빨리 DB에 데이터를 쓰는 동안 몇 가지 실험을 수행했습니다. 실험 후 스냅 샷 볼륨을 복원하고 VM + postgres를 시작했습니다.
- 데이터와 로그 볼륨을 동시에 가깝게 스냅 샷-결과 : DB 복구
- 스냅 샷 데이터 볼륨 우선, 로그 볼륨 ~ 1 분 후-결과 : DB 복구
- 스냅 샷 로그 볼륨 우선, 데이터 볼륨 ~ 1 분 후-결과 : DB 복구
- WAL 체크 포인트가 데이터 파일에 새 데이터를 쓴 후 ~ 3 분 후 스냅 샷 로그 볼륨, 데이터 볼륨 : 결과 : DB 복구
따라서 두 스냅 샷이 모두 볼륨 수준에서 일관되고 상대적으로 서로 가까이있는 한 WAL / Log 볼륨 스냅 샷 시간에 따라 일관된 DB 사본을 얻을 수있는 한 테스트 결과가 나왔습니다.
내 질문 : 안전합니까? 테스트에서 누락 된 코너 케이스는 무엇이고 무엇이 잘못 될 수 있습니까?
Postgres의 문서는 이것이 안전하지 않다는 것을 나타내지 만 테스트는 매우 강력하다는 것을 나타냅니다 : http://www.postgresql.org/docs/9.1/static/backup-file.html
데이터베이스가 여러 파일 시스템에 분산 된 경우 모든 볼륨의 정확히 동시에 고정 된 스냅 샷을 얻을 수있는 방법이 없을 수 있습니다. 예를 들어, 데이터 파일과 WAL 로그가 다른 디스크에 있거나 테이블 공간이 다른 파일 시스템에있는 경우 스냅 샷이 동시에 있어야하므로 스냅 샷 백업을 사용하지 못할 수 있습니다. 이러한 상황에서 일관된 스냅 샷 기술을 신뢰하기 전에 파일 시스템 설명서를주의해서 읽으십시오.
참고 : 예, PostgreSQL을 핫 백업 모드로 설정하거나 스토리지의 VMware 통합을 사용하여 VM 자체를 중지하는 등의 다른 옵션이 일관성을 유지하는지 알고 있지만 속도, 편의성, 스토리지 전용 솔루션을 찾고 있습니다. 고객에게 영향을주지 않습니다.