postgresql의 일관된 백업을위한 스토리지 스냅 샷-다른 데이터 및 로그 볼륨


11

우리는 많은 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 자체를 중지하는 등의 다른 옵션이 일관성을 유지하는지 알고 있지만 속도, 편의성, 스토리지 전용 솔루션을 찾고 있습니다. 고객에게 영향을주지 않습니다.


2
스토리지 그룹 인 Nimble Storage가 오늘 보호 그룹의 일부로 생성 된 스냅 샷이 정확히 같은 시점에 볼륨 전체에서 일관되게 진행되었다는 사실을 분명히 밝혔습니다. 그러나 Postgres 테스트에서 동시에 찍은 스냅 샷을 견딜 수있을 정도로 견고한 것처럼 누군가 의견이 있으면 여전히 관심이 있습니다.
Steve R.

데이터와 로그 볼륨이 모두 동일한 스냅 샷 그룹에있는 경우 "스냅 샷 데이터 볼륨을 먼저 기록하고 ~ 1 분 후 로그 볼륨"이라고 할 때의 의미는 무엇입니까? 하나의 스냅 샷 그룹에 데이터와 로그 볼륨을 넣고 스냅 샷을 수행 한 다음 인스턴스 스냅 샷 복구와 같은 스냅 샷에서 DB를 복원합니다. Oracle에 대한 스냅 샷 기술을 사용하기 전에 EMC 스토리지 기반 백업을 테스트했습니다. 매우 신뢰할 수 있습니다.
fairybetty

답변:


2

인용 한 문서에 모든 내용이 나와 있지만, 동시에 찍은 스냅 샷과 관련하여 공급 업체의 주장을 확인하려는 경우에는 책임을지지 않습니다. 무언가를 발견하는 방법은 WAL 시스템을 보다 구체적 으로 스트레스 테스트하는 것일 수 있습니다 .

예를 들어 pgbench 기반 테스트 외에도 pg_switch_xlog()로그 회전, 짧고 긴 체크 포인트 간격 (단축 및 연장 checkpoint_timeoutcheckpoint_timeout) 을 위해 임의의 호출을 추가 하여 작거나 큰 월 파일 크기를 사용하십시오.

내가 누락 된 것이 없다면 스냅 샷을 동시에 찍지 않기 때문에 복구 된 DB를 운이 좋은 타이밍이라고 생각합니다. 마지막 경우, 현재 xlog 위치가 예를 들어, 로그 스냅 샷을 생성했다고 가정 해보십시오 0/A1C0FFEE. 그런 다음 시스템에 3 분 동안 특히 많은로드가 발생하여 WAL 파일을 완전히 순환하게되며 이제 0/DEADBEEF데이터 스냅 샷 을 만들 때 DB 가 사용됩니다. 복원을 시도하면 데이터 스냅 샷 시점에 기록중인 WAL 파일이 오랫동안 사라져 복구에 실패합니다.

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.