PostgreSQL 9 관리 요리책(Riggs/Krosing)의 "독립형 핫 물리적 데이터베이스 백업" 레시피에 따라 Postgresql 9.0.8 데이터베이스의 물리적 백업을 수행하는 스크립트를 작성했지만 Windows Server 2008 R2에 맞게 조정했습니다. .
rsync를 사용하여 모든 데이터 파일(pg_xlog 디렉터리 제외)을 복사하는 레시피의 4단계에서는 robocopy.exe를 사용하고 있습니다(rsync는 *nix 유틸리티이고 Windows를 사용하고 있기 때문입니다). 문제는 파일 중 하나를 복사할 수 없고 "액세스가 거부되었습니다"라는 메시지가 나타나는 경우가 많다는 것입니다. "액세스가 거부되었습니다" 메시지와 함께 파일을 직접 복사하지 못했습니다.긴백업 스크립트가 실패한 후 - 다시 시도할 수 있는 간헐적인 문제는 아닙니다. PostgreSQL 프로세스를 다시 시작한 후에만 파일을 복사할 수 있습니다. 항상 다른 파일입니다. 지난 밤에는 %PGDATADIR%\5432\base\24609\38122 였습니다.
이 문제를 경험한 적이 있는지, 이 문제를 해결하기 위해 무엇을 했는지 듣고 싶습니다. 나는 다음을 고려하고 있다:
- 백업 직전에 PostgreSQL 서버를 다시 시작합니다(해킹임을 인정합니다).
- VSHADOW, DISKSHADOW 및 hobocopy와 같은 열린 파일을 복사할 수 있는 일종의 유틸리티 사용(참고: robocopy 아님)
- PostgreSQL에 모든 잠금을 해제하도록 지시하는 방법이 있을까요?
- [추가] 아래 참조 - 정기적인 "진공"을 추가하면 증상이 제거되는 것처럼 보입니다.
답변1
좋아요, 가장 먼저 해야 할 일은 요리책을 치워두세요. 대신 가서 읽어보세요백업에 관한 Postgres 매뉴얼 섹션. 전체 장을 읽으십시오. 그렇게 길지는 않습니다.
(아마도 이 책과 책 사이에 몇 가지 유사점을 발견하게 될 것입니다. 대부분의 Postgres 책은 매뉴얼을 예쁘게 꾸민 버전이지만, 항상 매뉴얼을 기본 참조로 삼아 작업해야 합니다.)
아래에서 사용할 모든 용어는 매뉴얼에서 가져온 것입니다(따라서 읽기 과제를 건너뛸 수 있다고 생각했다면 건너뛸 수 없습니다. 그렇게 하면 끔찍하게 혼란스러울 수 있습니다).
이제 실제 문제를 살펴보겠습니다. Unix 솔루션은 Windows로 직접 이식할 수 없는 경우가 많으며 이는 이러한 경우 중 하나입니다. *nix 시스템은 조작 중인 파일을 기꺼이 잡아냅니다. Windows에서는 사용자가 보고 있는 오류가 발생합니다.
이를 처리하는 방법은 수행 중인 백업 종류에 따라 다릅니다.
파일 시스템 수준 백업
당신이하고 있다면"파일 시스템 수준 백업"너~ 해야 하다서버를 종료합니다. 마침표, 토론 종료, 다른 옵션은 없습니다. 해당 유형의 백업을 신뢰할 수 있으려면 데이터베이스를 완전히 종료해야 합니다(만약 얻고 있는 백업이 신뢰할 수 없다면 무슨 의미가 있습니까?).
지속적인 아카이빙/특정 시점 복구 및 슬레이브 서버
당신이하고 있다면기본 백업설정의 일부로특정 시점 복구및 로그 전달에는 두 가지 옵션이 있습니다.
- 어쨌든 서버를 종료하세요.
- 열린 파일을 복사할 수 있는 도구를 사용하십시오(질문의 옵션 (2)).
그런 다음 특정 시점 복구/로그 전달에 대한 나머지 문서에 따라 슬레이브 서버를 생성하는 과정을 진행합니다.
데이터베이스 서버를 디스크에 복사하려면 슬레이브를 중지하고 백업한 후 다시 시작하기만 하면 됩니다. 세상은 계속해서 마스터 서버를 켜고 슬레이브는 다시 시작할 때 놓친 부분을 따라잡을 것입니다.
또한 기본 백업과 일반적으로 슬레이브에 제공하는 롤링된 트랜잭션 로그를 신뢰할 수 있는 데이터베이스 백업으로 사용할 수도 있습니다. 이것은 귀하의 질문에서 달성하려는 것과 가장 가까운 것 같지만 대신 제가 설명한 슬레이브 백업을 권장합니다. - 더 많은 이점(상시 대기가 있음)과 마스터 서버에 대한 작업이 적음(아니요) 백업의 트랜잭션 로그를 롤링하기 위한 추가 검사점).
다른 것
위의 어느 것도 마음에 들지 않으면 계속 사용하고 있는 것입니다.SQL 덤프.
단점도 있습니다. Postgres는 덤프될 때 각 테이블을 잠가야 하며(즉, 데이터베이스에 대한 쓰기가 차단됨을 의미함) SQL 덤프는 다른 옵션보다 느립니다.
귀하의 데이터베이스가 실제 크기라면 이 방법을 권장하지 않습니다.