24.3. 지속적인 아카이빙 및 특정 시점 토토 캔(PITR)

24.3.1. WAL 설정 보관

추상적인 의미에서는 달리기PostgreSQL시스템은 무기한 생산합니다. WAL 레코드의 긴 시퀀스. 시스템이 물리적으로 분할됨 이 시퀀스를 WAL로 변환세그먼트 파일, 일반적으로 각각 16MB입니다(세그먼트 크기에 따라 건물을 지을 때 변경될 수 있음포스트그레SQL). 세그먼트 파일이 제공됩니다. 추상 WAL에서의 위치를 반영하는 숫자 이름 순서. WAL 아카이빙을 사용하지 않을 때 시스템은 일반적으로 몇 개의 세그먼트 파일만 생성한 다음"재활용"더 이상 필요하지 않은 이름을 변경하여 파일을 더 높은 세그먼트 번호로 분할합니다. 다음과 같이 가정됩니다. 내용이 마지막 체크포인트보다 앞에 있는 세그먼트 파일 더 이상 관심이 없으며 재활용할 수 있습니다.

WAL 데이터를 보관할 때 다음의 내용을 캡처해야 합니다. 각 세그먼트 파일이 채워지면 해당 데이터를 저장합니다. 세그먼트 파일이 재사용을 위해 재활용되기 전 어딘가에 있습니다. 애플리케이션과 사용 가능한 하드웨어에 따라 다양한 방법이 있을 수 있습니다."저장 중 데이터가 어딘가에 있습니다.": 세그먼트 파일을 다른 머신에 있는 NFS 마운트 디렉토리를 테이프 드라이브(테이프 드라이브를 식별할 수 있는 방법이 있는지 확인) 각 파일의 원래 이름) 또는 함께 일괄적으로 굽습니다. CD로 저장하거나 완전히 다른 것으로 저장합니다. 제공하기 위해 최대한의 유연성을 갖춘 데이터베이스 관리자입니다.PostgreSQL만들지 않으려고 노력합니다 아카이빙이 수행되는 방법에 대한 모든 가정. 대신에,PostgreSQL하자 관리자는 복사하기 위해 실행할 쉘 명령을 지정합니다. 완성된 세그먼트 파일을 어디로든 이동해야 합니다. 명령 다음과 같이 간단할 수도 있습니다.cp, 아니면 복잡한 셸 스크립트를 호출할 수 있습니다. 모두 귀하에게 달려 있습니다.

WAL 보관을 활성화하려면 다음을 설정하세요.archive_mode구성 매개변수 대상켜짐그리고 에서 사용할 쉘 명령을 지정하십시오.archive_command구성 매개변수. 실제로 이러한 설정은 항상 에 배치됩니다.postgresql.conf파일. 에서archive_command, 모두%p은 다음의 경로 이름으로 대체됩니다. 보관할 파일, 임의의 경우%f이 파일 이름으로만 대체됩니다. (경로 이름은 현재 작업 디렉터리, 즉 클러스터의 데이터 디렉토리.) 쓰기%%필요하다면 실제 삽입%문자 명령. 가장 간단하고 유용한 명령은 다음과 같습니다.

archive_command = '테스트! -f /mnt/server/archivedir/%f && cp %p /mnt/server/archivedir/%f' # 유닉스
archive_command = '복사 "%p" "C:\\server\\archivedir\\%f"' # Windows

보관 가능한 WAL 세그먼트를 디렉토리에 복사합니다/mnt/서버/아카이브디렉터리. (이것은 예를 들어 권장 사항이 아니며 일부에서는 작동하지 않을 수도 있습니다. 플랫폼.) 이후%p그리고%f매개변수가 대체되었습니다. 실행되는 실제 명령은 다음과 같습니다.

테스트! -f /mnt/server/archivedir/00000001000000A900000065 && cp pg_xlog/00000001000000A900000065 /mnt/server/archivedir/00000001000000A900000065

비슷한 명령이 각 새 파일에 대해 생성됩니다. 보관되었습니다.

보관 명령은 다음의 소유권으로 실행됩니다. 동일한 사용자입니다.포스트그레SQL서버가 다음 계정으로 실행 중입니다. 이후 아카이브되는 일련의 WAL 파일에는 효과적으로 데이터베이스에 있는 모든 내용을 확인하고 싶을 것입니다. 보관된 데이터는 엿보는 눈으로부터 보호됩니다. 예를 들어, 그룹 또는 전체 읽기 권한이 없는 디렉토리에 보관 액세스합니다.

보관 명령이 0을 반환하는 것이 중요합니다. 상태는 성공한 경우에만 가능합니다. 결과가 0이 되면,포스트그레SQL다음과 같이 가정합니다 파일이 성공적으로 보관되었으며 제거되거나 그것을 재활용하십시오. 그러나 0이 아닌 상태는 다음과 같습니다.PostgreSQL파일이 보관되지 않았습니다. 성공할 때까지 주기적으로 다시 시도합니다.

보관 명령은 일반적으로 거부하도록 설계되어야 합니다. 기존 아카이브 파일을 덮어쓰려면 이것은 귀하의 무결성을 유지하는 중요한 안전 기능 관리자 오류(예: 두 개의 서로 다른 서버를 동일한 아카이브로 출력 디렉토리).

제안된 아카이브 명령을 테스트하여 다음을 수행하는 것이 좋습니다. 실제로 기존 파일을 덮어쓰지 않는지 확인하세요.그리고 0이 아닌 값을 반환합니다 이 경우 상태. 위의 Unix용 예제 명령 별도의를 포함하여 이를 보장합니다.테스트단계. 일부 Unix 플랫폼에서는,cp다음과 같은 스위치가 있습니다-i동일한 작업을 더 적게 수행하는 데 사용할 수 있습니다. 장황하게 설명하지만 확인 없이 이에 의존해서는 안 됩니다. 올바른 종료 상태가 반환됩니다. (특히 GNUcp다음의 경우 상태 0을 반환합니다.-i이(가) 사용되었으며 대상 파일이 이미 존재합니다.아님원하는 동작입니다.)

보관 설정을 설계하는 동안 무엇을 할 것인지 고려하십시오. 아카이브 명령이 반복적으로 실패하면 발생합니다. 측면에서 운영자 개입이 필요하거나 아카이브가 부족합니다. 공간의. 예를 들어, 테이프에 쓰는 경우 이런 일이 발생할 수 있습니다. 오토체인저 없이; 테이프가 가득 차면 더 이상 아무것도 없습니다 테이프를 교체할 때까지 보관할 수 있습니다. 당신은 보장해야 오류 조건이나 인간 운영자에 대한 요청은 상황이 해결될 수 있도록 적절하게 보고되었습니다. 합리적으로 빠르게. 그만큼pg_xlog/디렉토리는 다음까지 WAL 세그먼트 파일로 계속 채워집니다. 상황이 해결되었습니다. (다음을 포함하는 파일 시스템인 경우pg_xlog/채워지고,PostgreSQLPANIC 종료를 수행합니다. 아니요 이전 트랜잭션은 손실되지만 데이터베이스는 여유 공간을 확보할 때까지 사용할 수 없습니다.)

보관 명령의 속도는 중요하지 않으므로 너무 길다 서버의 평균 속도를 따라잡을 수 있기 때문입니다. WAL 데이터를 생성합니다. 정상 작동은 계속됩니다. 보관 프로세스가 약간 뒤쳐집니다. 보관이 중단되는 경우 상당히 뒤쳐지면 데이터 양이 늘어납니다. 재해가 발생하면 손실됩니다. 그것은 또한 그 말은pg_xlog/디렉토리는 아직 보관되지 않은 세그먼트 파일이 많이 포함되어 있습니다. 결국 사용 가능한 디스크 공간을 초과할 수 있습니다. 당신은 조언을 아카이빙 프로세스를 모니터링하여 작동하는지 확인합니다. 당신 뜻대로요.

보관 명령을 작성할 때 다음을 가정해야 합니다. 보관할 파일 이름은 최대 64자까지 가능하며 ASCII 문자, 숫자, 점의 조합을 포함할 수 있습니다. 원래 상대 경로를 기억할 필요는 없습니다. (%p) 하지만 기억할 필요가 있는 것은 파일 이름(%f).

WAL 아카이브를 사용하면 복원이 가능하지만 귀하의 데이터에 대한 모든 수정 사항포스트그레SQL데이터베이스, 복원되지 않습니다. 구성 파일에 대한 변경 사항(즉,postgresql.conf, pg_hba.conf그리고pg_ident.conf), 수동으로 편집되므로 SQL 작업을 통해서가 아니라. 당신은 백업할 위치에 있는 구성 파일 정기적인 파일 시스템 백업 절차. 참조섹션 18.2어떻게 구성 파일을 재배치합니다.

아카이브 명령은 완료된 WAL에서만 호출됩니다. 세그먼트. 따라서 서버가 WAL을 거의 생성하지 않는 경우 교통 정체(또는 여유 시간이 있는 경우)가 있을 수 있습니다. 거래 완료와 거래 완료 사이의 긴 지연 아카이브 저장소에 안전하게 기록됩니다. 나이를 제한하려면 보관되지 않은 데이터는 설정할 수 있습니다.archive_timeout서버가 다음 위치에서 새로운 WAL 세그먼트 파일로 전환하도록 강제합니다. 적어도 그렇게 자주. 조기 종료된 보관 파일에 유의하세요. 강제 전환으로 인해 여전히 완전히 동일한 길이 전체 파일. 따라서 매우 짧게 설정하는 것은 현명하지 않습니다.archive_timeout— 그것은 당신을 부풀게 할 것입니다 아카이브 저장.archive_timeout1분 정도의 설정이 일반적으로 합리적입니다.

또한 다음을 사용하여 수동으로 세그먼트 전환을 강제할 수 있습니다.pg_switch_xlog, 원한다면 방금 완료된 거래가 즉시 보관되도록 하세요. 가능합니다. WAL 관리와 관련된 기타 유틸리티 기능은 다음과 같습니다. 에 나열됨테이블 9-56.

언제아카이브_모드is꺼짐일부 SQL 명령은 WAL을 방지하도록 최적화되었습니다. 로깅(설명됨)섹션 14.4.7. 보관하는 경우 WAL 명령문 중 하나를 실행하는 동안 켜졌습니다. 아카이브 복구에 필요한 정보가 충분하지 않습니다. (충돌 복구는 영향을 받지 않습니다.) 이러한 이유로,archive_mode서버에서만 변경할 수 있습니다. 시작합니다. 그러나archive_command될 수 있습니다 구성 파일을 다시 로드하여 변경되었습니다. 당신이 원한다면 일시적으로 보관을 중지하는 한 가지 방법은 설정하는 것입니다.archive_command빈 문자열로 (''). 이로 인해 WAL 파일이 축적하다pg_xlog/다음까지 일하는 중archive_command이다 다시 설립되었습니다.

24.3.2. 기본 백업 만들기

기본 백업을 만드는 절차는 비교적 간단합니다:

1. WAL 보관이 활성화되어 작동하는지 확인하세요.

2. 슈퍼유저로 데이터베이스에 연결하고, 명령:

   SELECT pg_start_backup('라벨');

   어디에서라벨당신이 원하는 문자열은 무엇입니까? 이 백업 작업을 고유하게 식별하는 데 사용하려고 합니다. (한 가지 좋은 방법은 원하는 전체 경로를 사용하는 것입니다. 백업 덤프 파일을 넣습니다.)pg_start_backup생성백업 라벨파일, 호출됨backup_label, 클러스터 디렉터리에서 백업에 대한 정보입니다.

   클러스터 내의 어떤 데이터베이스를 사용하는지는 중요하지 않습니다. 이 명령을 실행하려면 에 연결하세요. 결과를 무시해도 됩니다 함수에 의해 반환됩니다. 하지만 오류가 보고되면 처리하세요. 계속하기 전에 그 내용을 확인하세요.

   기본적으로,pg_start_backup시간이 오래 걸릴 수 있습니다. 마무리. 체크포인트를 수행하기 때문입니다. 체크포인트에 필요한 I/O는 상당한 기간, 기본적으로 절반 체크포인트 간 간격(구성 매개변수 참조)checkpoint_completion_target). 일반적으로 이것이 당신이 원하는 것입니다. 쿼리 처리에 영향을 미칩니다. 그냥 시작하고 싶다면 가능한 한 빨리 백업하려면 다음을 사용하세요.

   SELECT pg_start_backup('라벨', true);

   이렇게 하면 체크포인트가 다음과 같이 빨리 완료됩니다. 가능합니다.

3. 편리한 방법을 사용하여 백업을 수행하십시오. 다음과 같은 파일 시스템 백업 도구타르또는cpio. 꼭 필요한 것도 아니고 데이터베이스의 정상적인 작동을 중지하는 것이 바람직합니다. 너는 이렇게 해.

4. 다시 슈퍼유저로 데이터베이스에 연결하고 발행하십시오. 명령:

   SELECT pg_stop_backup();

   이것은 백업 모드를 종료하고 다음을 수행합니다. 다음 WAL 세그먼트로 자동 전환됩니다. 이유는 스위치는 마지막 WAL 세그먼트 파일을 정렬하는 것입니다. 백업 간격 동안 기록된 내용은 즉시 준비됩니다. 아카이브.

5. 백업 중에 사용된 WAL 세그먼트 파일이 보관처리가 완료되었습니다. 다음으로 식별되는 파일:pg_stop_backup의 결과가 마지막입니다 완전한 백업 세트를 구성하는 데 필요한 세그먼트 파일.pg_stop_backup그렇습니다 마지막 세그먼트가 보관될 때까지 반환되지 않습니다. 이러한 파일의 보관은 다음 이후 자동으로 수행됩니다. 이미 구성했습니다archive_command. 대부분의 경우 이런 일이 발생합니다. 빠르지만 보관 시스템을 모니터링하는 것이 좋습니다. 지연이 발생하지 않도록 합니다. 아카이브 프로세스가 있는 경우 아카이브 명령 실패로 인해 뒤쳐진 아카이브가 성공할 때까지 계속 재시도하고 백업이 완료되었습니다. 시간 제한을 두고 싶으시다면 실행pg_stop_backup, 적절한 설정statement_timeout값.

사용할 수 있는 일부 백업 도구는 경고를 내보냅니다. 또는 복사하려는 파일이 변경되는 동안 오류가 발생합니다. 복사가 진행됩니다. 이러한 상황은 정상이며 오류가 아닙니다. 활성 데이터베이스의 기본 백업을 수행합니다. 그래서 당신은해야합니다 이러한 종류의 불만사항을 다른 불만사항과 구별할 수 있는지 확인하십시오. 실제 오류. 예를 들어, 일부 버전은rsync다음에 대한 별도의 종료 코드를 반환합니다."사라진 소스 파일"그리고 당신은 할 수 있습니다 이 종료 코드를 오류가 아닌 것으로 받아들이도록 드라이버 스크립트를 작성하십시오. 사건. 또한 GNU의 일부 버전타르분별할 수 없는 오류 코드를 반환합니다. 파일이 잘린 경우 치명적인 오류가 발생합니다.타르복사 중이었습니다. 다행히 GNU타르버전 1.16 이상 다음으로 종료1파일이 변경된 경우 백업 중 및2기타용 오류.

금액에 대해 크게 걱정할 필요는 없습니다. 사이에 경과된 시간pg_start_backup그리고 실제의 시작 백업 또는 백업 종료 사이pg_stop_backup; 몇 분만 지연해도 안 돼 무엇이든 다치게 하세요. (단, 일반적으로 서버를 실행하는 경우full_page_writes비활성화되었습니다. 다음 사이에 성능 저하가 나타납니다.pg_start_backup그리고pg_stop_backup, 이후full_page_writes동안 효과적으로 강제됩니다. 백업 모드.) 이러한 단계가 수행되었는지 확인해야 합니다. 중복될 가능성 없이 순서대로 진행하거나 백업을 무효화합니다.

백업 덤프에 모든 파일이 포함되어 있는지 확인하십시오. 데이터베이스 클러스터 디렉터리 아래(예:/usr/local/pgsql/data). 당신이 사용하는 경우 이 디렉토리 아래에 상주하지 않는 테이블스페이스는 그것들도 포함하도록 주의하십시오(그리고 백업이 덤프는 심볼릭 링크를 링크로 보관합니다. 그렇지 않으면 복원됩니다. 테이블스페이스를 엉망으로 만들 것입니다.)

그러나 백업 덤프에서 다음 파일을 생략할 수 있습니다.pg_xlog/하위 디렉토리 클러스터 디렉토리. 이 약간의 합병증은 가치가 있습니다 복원할 때 실수할 위험이 줄어들기 때문입니다. 이것은 다음과 같은 경우 쉽게 정리할 수 있습니다.pg_xlog/은 클러스터 외부를 가리키는 심볼릭 링크 어쨌든 성능을 위한 일반적인 설정인 디렉토리 이유.

백업을 사용하려면 모든 것을 보관해야 합니다. 파일 도중 및 이후에 생성된 WAL 세그먼트 파일 시스템 백업. 이를 수행하는 데 도움이 되도록,pg_stop_backup함수는 다음을 생성합니다백업 기록 파일즉시 저장됩니다. WAL 아카이브 영역으로 이동합니다. 이 파일의 이름은 첫 번째 파일의 이름을 따서 지정되었습니다. WAL 세그먼트 파일을 활용해야 합니다. 백업. 예를 들어, 시작 WAL 파일이 다음과 같은 경우0000000100001234000055CD백업 기록 파일 다음과 같은 이름이 지정됩니다.0000000100001234000055CD.007C9330.backup. ( 파일 이름의 두 번째 부분은 정확한 위치를 나타냅니다. WAL 파일 내에 있으며 일반적으로 무시할 수 있습니다.) 일단 파일 시스템 백업과 WAL 세그먼트를 안전하게 보관했습니다. 백업 중에 사용되는 파일(백업에 지정된 대로) 히스토리 파일), 이름이 숫자로 표시된 모든 보관된 WAL 세그먼트 파일 시스템 백업을 토토 캔하는 데 더 이상 필요하지 않으며 삭제될 수 있습니다. 그러나 여러 개를 유지하는 것을 고려해야 합니다. 백업 세트를 사용하여 토토 캔할 수 있다는 것을 절대적으로 확신할 수 있습니다. 데이터.

백업 기록 파일은 작은 텍스트 파일입니다. 그것 귀하가 제공한 라벨 문자열을 포함합니다.pg_start_backup뿐만 아니라 시작 및 종료 시간 및 백업의 WAL 세그먼트. 당신이 사용한 경우 관련 덤프 파일이 보관되는 위치를 식별하는 레이블 보관된 기록 파일은 어떤 덤프 파일인지 알려주기에 충분합니다. 복원하려면 그렇게 해야 합니다.

보관된 모든 WAL 파일을 보관해야 하므로 마지막 기본 백업으로 돌아가서 기본 백업 사이의 간격 백업은 일반적으로 저장 용량에 따라 선택해야 합니다. 보관된 WAL 파일을 확장하고 싶습니다. 당신은 또한 고려해야합니다 회복하는 경우 회복에 소요될 준비가 된 기간 필요해야 합니다. 시스템은 해당 항목을 모두 재생해야 합니다. WAL 세그먼트, 오랜 시간이 걸렸다면 다소 시간이 걸릴 수 있음 마지막 기본 백업 이후의 시간입니다.

또한 주목할 만한 점은 다음과 같습니다.pg_start_backup함수는 이름이 지정된 파일을 만듭니다.backup_label데이터베이스 클러스터 디렉토리는 다음에 의해 다시 제거됩니다.pg_stop_backup. 이 파일은 물론 백업 덤프 파일의 일부로 보관됩니다. 백업 라벨 파일에는 귀하가 제공한 라벨 문자열이 포함되어 있습니다.pg_start_backup및 해당 시간pg_start_backup실행되었으며 시작 WAL 파일의 이름입니다. 혼란스러운 경우에는 따라서 백업 덤프 파일 내부를 살펴보고 덤프 파일이 어떤 백업 세션에 포함되었는지 정확히 확인 에서.

서버가 작동하는 동안 백업 덤프를 만드는 것도 가능합니다 중지되었습니다. 이 경우에는 분명히 사용할 수 없습니다.pg_start_backup또는pg_stop_backup그러므로 당신은 어떤 백업 덤프가 있는지 추적하려면 사용자 장치에 맡겨야 합니다. 관련 WAL 파일이 얼마나 오래 전으로 거슬러 올라가는지. 그것은 일반적으로 지속적인 보관 절차를 따르는 것이 더 좋습니다. 위.

24.3.3. 연속을 사용하여 토토 캔 아카이브 백업

좋아요, 최악의 상황이 발생했고 당신은 회복해야 합니다 당신의 백업. 절차는 다음과 같습니다.

1. 서버가 실행 중이면 중지하세요.

2. 공간이 있으면 전체 클러스터를 복사하십시오 데이터 디렉터리 및 모든 테이블스페이스를 임시 위치로 복사 나중에 필요할 경우를 대비해. 이 예방 조치는 시스템에 충분한 여유 공간이 있어야 합니다. 기존 데이터베이스의 복사본 두 개를 보관하세요. 그렇지 않으면 공간이 충분하면 최소한 의 내용pg_xlog클러스터 데이터 디렉토리의 하위 디렉토리 시스템이 가동되기 전에 보관되지 않은 로그가 포함되어 있습니다. 다운.

3. 아래의 모든 기존 파일과 하위 디렉터리를 정리합니다. 클러스터 데이터 디렉터리 및 루트 디렉터리 아래 사용 중인 테이블스페이스 중 하나입니다.

4. 기본 백업에서 데이터베이스 파일을 복원하십시오. 수 올바른 소유권으로 복원되도록 주의하세요. (데이터베이스 시스템 사용자가 아님루트!) 및 올바른 권한이 있어야 합니다. 만약에 테이블스페이스를 사용하고 있다면 다음을 확인해야 합니다. 의 심볼릭 링크pg_tblspc/있었다 올바르게 복원되었습니다.

5. 다음에 있는 모든 파일을 제거pg_xlog/; 이것은 백업 덤프에서 나온 것입니다 그러므로 아마도 현재보다는 더 이상 사용되지 않을 것입니다. 만약에 당신은 보관처리하지 않았습니다pg_xlog/에 그런 다음 주의 깊게 다시 생성하세요. 설정한 경우 심볼릭 링크로 다시 설정하십시오. 예전엔 그랬지.

6. 당신이 저장한 WAL 세그먼트 파일을 보관 해제한 경우 2단계에서 다음 위치에 복사하세요.pg_xlog/. (복사하는 것이 가장 좋습니다. 해당 파일을 이동하면 수정되지 않은 파일이 그대로 유지됩니다. 문제가 발생하면 다시 시작해야 합니다.)

7. 복구 명령 파일 생성recovery.conf클러스터 데이터 디렉토리 (참조토토 캔 설정). 일시적으로 수정하고 싶을 수도 있습니다.pg_hba.conf보통을 방지하기 위해 토토 캔가 완료되었다고 확신할 때까지 사용자는 연결하지 못합니다. 일했다.

8. 서버를 시작하세요. 서버가 복구 모드로 전환됩니다. 계속해서 보관된 WAL 파일을 읽어보세요. 필요합니다. 다음 사유로 인해 복구가 종료된 경우 외부 오류가 발생하면 서버를 다시 시작하면 됩니다. 회복을 계속할 것입니다. 복구가 완료되면 프로세스가 완료되면 서버 이름이 변경됩니다.recovery.conf에토토 캔.완료(우연히 방지하기 위해 나중에 충돌이 발생할 경우 복구 모드로 다시 들어가기) 그런 다음 일반 데이터베이스 작업을 시작합니다.

9. 데이터베이스의 내용을 검사하여 다음이 있는지 확인하십시오. 당신이 원하는 곳으로 회복되었습니다. 그렇지 않은 경우 단계로 돌아갑니다. 1. 모든 것이 정상이면 복원을 통해 사용자를 허용합니다.pg_hba.conf정상으로.

이 모든 것의 핵심 부분은 토토 캔 명령을 설정하는 것입니다 토토 캔 방법과 토토 캔 범위를 설명하는 파일 토토 캔가 실행되어야 합니다. 당신은 사용할 수 있습니다recovery.conf.sample(일반적으로 다음 위치에 설치됩니다. 설치공유/디렉토리)를 프로토타입. 반드시 지정해야 하는 한 가지는recovery.conf이것이restore_command, 이는 다음과 같습니다PostgreSQL보관된 WAL을 다시 얻는 방법 파일 세그먼트. 처럼archive_command, 이것은 쉘 명령 문자열입니다. 다음을 포함할 수 있습니다.%f, 대체됨 원하는 로그 파일 이름으로, 그리고%p, 복사할 경로 이름으로 대체됨 로그 파일을 . (경로 이름은 현재 경로에 상대적입니다. 작업 디렉터리, 즉 클러스터의 데이터 디렉터리입니다.) 쓰기%%실제 내용을 삽입해야 하는 경우%명령의 문자입니다. 는 가장 간단하고 유용한 명령은 다음과 같습니다.

restore_command = 'cp /mnt/server/archivedir/%f %p'

이전에 보관된 WAL 세그먼트를 다음에서 복사합니다. 디렉토리/mnt/서버/아카이브디렉터리. 당신 물론 훨씬 더 복잡한 것을 사용할 수도 있습니다. 심지어 운영자에게 마운트를 요청하는 쉘 스크립트도 마찬가지입니다. 적절한 테이프.

명령이 0이 아닌 종료 상태를 반환하는 것이 중요합니다 실패시. 명령할 것이다다음 파일에 대한 요청을 받습니다. 아카이브에 없습니다. 그렇다면 0이 아닌 값을 반환해야 합니다. 물었다. 이는 오류 조건이 아닙니다. 요청한 내용이 전부는 아닙니다. 파일은 WAL 세그먼트 파일이 됩니다. 너도 기대해야지 접미사가인 파일 요청.백업또는.역사. 또한의 기본 이름은%p경로가 다음과 다를 것입니다.%f; 그들이 그럴 것이라고 기대하지 마세요 상호 교환 가능.

아카이브에서 찾을 수 없는 WAL 세그먼트는 찾았다pg_xlog/; 이것은 사용을 허용합니다 보관되지 않은 최근 세그먼트 중 그러나 세그먼트는 아카이브에서 사용 가능한 파일이 파일보다 우선적으로 사용됩니다. 에서pg_xlog/. 시스템은 그렇지 않습니다 기존 내용을 덮어씁니다.pg_xlog/보관된 파일을 검색할 때.

일반적으로 복구는 사용 가능한 모든 WAL을 통해 진행됩니다. 세그먼트를 사용하여 데이터베이스를 현재 지점으로 복원합니다. 시간에 맞춰(또는 사용 가능한 WAL을 고려할 때 최대한 가깝게) 세그먼트). 따라서 정상적인 복구는"파일을 찾을 수 없습니다"메시지, 정확한 텍스트 선택에 따른 오류 메시지restore_command. 오류가 표시될 수도 있습니다. 어떤 이름의 파일에 대한 토토 캔 시작 시 메시지 좋아요00000001.역사. 이것은 또한 정상이며 단순 토토 캔에는 문제가 없음을 나타냅니다. 상황. 참조섹션 24.3.4토론을 위해.

이전 시점으로 복구하려는 경우(예: 주니어 DBA가 주요 트랜잭션을 삭제하기 직전 표), 필요한 중지 지점을 지정하기만 하면 됩니다.recovery.conf. 중지 지점을 지정할 수 있습니다. 로 알려진"토토 캔 대상", 날짜/시간 또는 특정 거래 완료 기준 신분증. 이 글을 쓰는 시점에서는 날짜/시간 옵션만 매우 유용합니다. 식별하는 데 도움이 되는 도구가 없기 때문에 사용할 수 있습니다. 사용할 거래 ID의 정확성.

복구 결과 WAL 데이터의 손상이 발견되면 복구 해당 시점에서 완료되고 서버는 시작되지 않습니다. 에서 이러한 경우 복구 프로세스는 다음에서 다시 실행될 수 있습니다. 시작, 지정"회복 대상"부패 지점 이전에 복구할 수 있도록 정상적으로 완료될 수 있습니다. 외부 복구에 실패한 경우 시스템 충돌이나 WAL 아카이브가 손상된 경우 등의 이유 액세스할 수 없는 경우 복구를 다시 시작하면 됩니다. 실패한 부분부터 거의 다시 시작됩니다. 복구 재시작 일반 작업의 체크포인트와 매우 유사하게 작동합니다. 서버 주기적으로 모든 상태를 디스크에 강제 적용한 다음 업데이트합니다.pg_control파일은 다음을 나타냅니다. 이미 처리된 WAL 데이터는 다시 스캔할 필요가 없습니다.

24.3.4. 타임라인

데이터베이스를 이전 시점으로 복원하는 기능 시간은 공상과학 소설과 유사한 몇 가지 복잡성을 만들어냅니다. 시간 여행과 평행 우주에 관한 이야기. 에서 데이터베이스의 원래 기록을 삭제했을 수도 있습니다. 화요일 저녁 5시 15분에 중요한 테이블이 있었지만 깨닫지 못했습니다. 수요일 정오까지 실수를 하세요. 당황하지 말고 나가세요. 백업, 화요일 저녁 5시 14분 시점으로 복원, 그리고 실행 중입니다. 에서이것데이터베이스의 역사 우주, 당신은 테이블을 전혀 떨어 뜨린 적이 없습니다. 하지만 당신이 가정 나중에 이것이 그다지 좋은 생각이 아니었음을 깨닫고 수요일 아침쯤으로 돌아가고 싶습니다. 원래 역사. 데이터베이스가 작동하는 동안에는 그렇게 할 수 없습니다. 실행 중이어서 WAL 시퀀스의 일부를 덮어썼습니다. 지금 원하는 시점까지 이어지는 세그먼트 파일 다시 돌아가십시오. 그래서 당신은 정말로 다음 시리즈를 구별하고 싶습니다. 특정 시점을 완료한 후 생성된 WAL 레코드 원본에서 생성된 것으로부터 복구 데이터베이스 기록.

이러한 문제를 해결하려면,PostgreSQL다음의 개념을 가지고 있습니다타임라인. 아카이브 복구가 수행될 때마다 완료되면 일련의 작업을 식별하기 위해 새로운 타임라인이 생성됩니다. 복구 후 생성된 WAL 레코드입니다. 타임라인 ID 번호는 WAL 세그먼트 파일 이름의 일부이므로 새로운 타임라인 이전에 생성된 WAL 데이터를 덮어쓰지 않습니다. 타임라인. 실제로 다양한 아카이브를 보관하는 것이 가능합니다. 타임라인. 쓸모없는 기능처럼 보일 수도 있지만, 종종 생명의 은인. 자신이 없는 상황을 생각해 보세요 어느 시점으로 복구해야 할지 확실히 알고 있으므로 복구해야 합니다. 시행착오를 거쳐 여러 시점 복구를 수행합니다. 오래된 역사에서 분기할 수 있는 가장 좋은 장소를 찾으세요. 없이 이 프로세스는 곧 관리하기 어려운 문제를 야기할 것입니다. 엉망. 타임라인을 사용하면 다음으로 복구할 수 있습니다.아무거나상태를 포함한 이전 상태 나중에 포기한 타임라인 브랜치에서.

새로운 타임라인이 생성될 때마다PostgreSQL생성"타임라인 기록"어떤 파일인지 보여주는 파일 타임라인은 언제부터 분기되었는지. 이 기록 파일은 시스템이 올바른 WAL 세그먼트를 선택할 수 있도록 하는 데 필요합니다. 여러 파일이 포함된 아카이브에서 복구할 때 파일 타임라인. 따라서 WAL 아카이브에 보관됩니다. WAL 세그먼트 파일과 같은 영역입니다. 기록 파일은 단지 작은 텍스트 파일이므로 저렴하고 보관하는 것이 적절합니다. (큰 세그먼트 파일과 달리) 무기한으로. 원하는 경우 기록 파일에 설명을 추가하여 이 특정 타임라인이 어떻게, 왜 등장했는지에 대한 나만의 메모 될. 그러한 의견은 다음과 같은 경우에 특히 가치가 있습니다. 그 결과로 다양한 타임라인이 만들어졌습니다. 실험.

복구의 기본 동작은 다음을 따라 복구하는 것입니다. 기본 백업을 수행할 당시와 동일한 타임라인입니다. 일부 하위 타임라인으로 복구하려는 경우(즉, 이후 자체적으로 생성된 일부 상태로 돌아가고 싶습니다. 복구 시도), 대상 타임라인 ID를 지정해야 합니다. 에서recovery.conf. 회복할 수 없습니다 베이스보다 일찍 분기된 타임라인으로 백업.

24.3.5. 팁과 예시

연속 보관 구성에 대한 몇 가지 팁이 제공됩니다. 여기.

archive_command = '테스트! -f /var/lib/pgsql/backup_in_progress || (테스트 ! -f /var/lib/pgsql/archive/%f && cp %p /var/lib/pgsql/archive/%f)'

터치 /var/lib/pgsql/backup_in_progress
psql -c "pg_start_backup('hot_backup')을 선택하십시오."
tar -cf /var/lib/pgsql/backup.tar /var/lib/pgsql/data/
psql -c "pg_stop_backup() 선택;"
rm /var/lib/pgsql/backup_in_progress
tar -rf /var/lib/pgsql/backup.tar /var/lib/pgsql/archive/

archive_command = 'pg_compresslog %p - | gzip  /var/lib/pgsql/archive/%f'

restore_command = 'gunzip < /mnt/server/archivedir/%f | pg_decompresslog - %p'

archive_command = 'local_backup_script.sh "%p" "%f"'

24.3.6. 주의사항

이 글을 쓰는 시점에는 다음과 같은 몇 가지 제한 사항이 있습니다. 지속적인 아카이빙 기술. 이러한 문제는 아마도 다음에서 해결될 것입니다. 향후 릴리스:

• 해시 인덱스에 대한 작업은 현재 WAL에 기록되지 않습니다. 따라서 재생은 이러한 인덱스를 업데이트하지 않습니다. 추천하는 해결 방법은 수동으로 수행하는 것입니다.REINDEX이후의 각 색인 토토 캔 작업을 완료합니다.

• 만약에PostgreSQL : 문서 : 8기본 백업이 수행되는 동안 명령이 실행됩니다. 가져온 다음 템플릿 데이터베이스를 가져옵니다.데이터베이스 생성복사된 내용이 수정됨 기본 백업이 진행되는 동안에도 가능합니다. 복구로 인해 이러한 수정이 발생하게 됩니다. 생성된 데이터베이스에도 전파됩니다. 이것은 물론 바람직하지 않습니다. 이러한 위험을 피하려면 다음을 수행하지 않는 것이 가장 좋습니다. 기지를 확보하는 동안 템플릿 데이터베이스를 수정하세요. 백업.

• PostgreSQL : 문서 : 8명령은 리터럴로 WAL 로그됩니다. 절대 경로이므로 테이블스페이스로 재생됩니다. 동일한 절대 경로를 가진 생성물. 이것은 아마도 로그가 다른 곳에서 재생되는 경우에는 바람직하지 않습니다. 기계. 로그가 남아 있어도 위험할 수 있습니다. 동일한 시스템에서 재생되지만 새로운 데이터로 재생됩니다. 디렉토리: 리플레이는 여전히 다음의 내용을 덮어씁니다. 원래 테이블스페이스 이로 인해 발생할 수 있는 문제를 방지하려면 정렬, 가장 좋은 방법은 다음 후에 새로운 기본 백업을 수행하는 것입니다. 테이블스페이스 생성 또는 삭제.

또한 기본값이라는 점에 유의해야 합니다.WAL형식은 상당히 부피가 큽니다. 많은 디스크 페이지 스냅샷을 포함합니다. 이 페이지 스냅샷은 문제를 해결해야 할 수도 있으므로 충돌 복구를 지원하도록 설계되었습니다. 부분적으로 작성된 디스크 페이지. 시스템 하드웨어에 따라 및 소프트웨어의 경우 부분 쓰기 위험이 충분히 작을 수 있습니다. 무시하려면 총계를 크게 줄일 수 있습니다. 다음을 사용하여 페이지 스냅샷을 꺼서 보관된 로그의 볼륨을 늘립니다.full_page_writes매개변수. (다음의 참고 사항과 경고를 읽어보세요.28장그렇게 하기 전에.) 페이지 끄기 스냅샷은 PITR 작업에 대한 로그 사용을 방해하지 않습니다. 향후 개발 분야는 보관된 WAL 데이터를 압축하는 것입니다. 경우에도 불필요한 페이지 사본을 제거하여full_page_writes켜져 있습니다. 그동안, 관리자는 페이지 수를 줄이고 싶어할 수도 있습니다. 체크포인트 간격을 늘려 WAL에 포함된 스냅샷 가능한 한 많은 매개변수를 사용하세요.