24.3.1. WAL 설정 토토 캔

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

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

WAL 보관을 활성화하려면 다음을 설정하세요.wal_level구성 매개변수아카이브(또는hot_standby), 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

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

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

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

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

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

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

토토 캔 명령의 속도는 중요하지 않습니다. 서버의 평균 속도를 따라잡을 수 있습니다. 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-57.

언제wal_levelis최소일부 SQL 명령은 다음을 피하기 위해 최적화되었습니다. WAL 로깅(에 설명된 대로)섹션 14.4.7. 보관하는 경우 또는 스트리밍 복제가 실행 중에 켜져 있었습니다. 이러한 진술 중 WAL에는 충분한 정보가 포함되어 있지 않습니다. 아카이브 복구를 위해. (충돌 복구는 영향을 받지 않습니다.) 이를 위해 이유,wal_level변경만 가능 서버 시작시. 하지만,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(아님pg_dump또는pg_dumpall). 필요하지도 않다 데이터베이스의 정상적인 작동을 중지하는 것도 바람직하지 않습니다. 네가 이러는 동안.

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클러스터 데이터 디렉토리 (보다와이즈 토토 : 문서 : 9.0 : 복구 구성). 너 일시적으로 수정하고 싶을 수도 있습니다.pg_hba.conf일반 사용자가 복구가 완료되었음을 확신할 때까지 연결 성공적인.

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

9. 데이터베이스의 내용을 검사하여 다음이 있는지 확인하십시오. 원하는 상태로 회복되었습니다. 그렇지 않은 경우 1단계로 돌아갑니다. 모든 것이 정상이면 사용자가 복원을 통해 연결할 수 있도록 허용하세요.pg_hba.conf정상으로.

이 모든 것의 핵심 부분은 복구를 설정하는 것입니다 복구 방법을 설명하는 구성 파일 및 복구가 얼마나 멀리 실행되어야 하는지. 당신은 사용할 수 있습니다recovery.conf.sample(일반적으로 설치공유/디렉토리)를 원기. 반드시 지정해야 하는 한 가지는recovery.conf이것은restore_command, 이는 다음을 알려줍니다.포스트그레SQL토토 캔된 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. 이 글을 쓰는 시점에서는 날짜/시간 옵션만 매우 유용합니다. 식별하는 데 도움이 되는 도구가 없기 때문에 사용할 수 있습니다. 사용할 거래 ID의 정확성.

복구가 손상된 WAL 데이터를 발견하면 복구는 다음 위치에서 중단됩니다. 해당 지점에서는 서버가 시작되지 않습니다. 그러한 경우에는 복구 프로세스를 처음부터 다시 실행할 수 있습니다. 에이"복구 대상"점 이전 복구가 정상적으로 완료될 수 있도록 손상을 제거합니다. 만약에 시스템 충돌과 같은 외부적인 이유로 복구가 실패하는 경우 또는 WAL 아카이브에 접근할 수 없게 된 경우, 복구는 간단히 다시 시작할 수 있으며 거의 ​​​​다시 시작됩니다 어디서부터 실패했는지. 복구 재시작은 다음과 같이 작동합니다. 정상 작동 시 체크포인트: 서버가 주기적으로 모든 상태를 디스크에 강제 적용한 다음 업데이트합니다.pg_control파일은 다음을 나타냅니다. 이미 처리된 WAL 데이터는 다시 스캔할 필요가 없습니다.

24.3.4. 타임라인

데이터베이스를 이전 시점으로 복원하는 기능 시간은 공상과학 소설과 유사한 몇 가지 복잡성을 만들어냅니다. 시간 여행과 평행 우주에 관한 이야기. 예를 들어, 데이터베이스의 원래 기록에서 화요일 저녁 5시 15분에 중요한 테이블이 있었지만 깨닫지 못했습니다. 수요일 정오까지 실수를 하세요. 당황하지 말고 나가세요. 백업, 화요일 저녁 5시 14분 시점으로 복원, 그리고 실행 중입니다. 안에이것데이터베이스의 역사 우주야, 넌 테이블을 떨어뜨린 적이 없어. 하지만 나중에 가정해보자 그다지 좋은 생각은 아니었음을 깨닫고 다시 돌아가고 싶습니다. 원래 역사에서는 수요일 아침 어느 때까지였습니다. 너 데이터베이스가 실행되는 동안에는 불가능합니다. 그 당시의 WAL 세그먼트 파일 중 일부를 덮어썼습니다. 이제 다시 돌아갈 수 있기를 바랍니다. 따라서 이를 방지하려면 이후에 생성된 일련의 WAL 레코드를 구별해야 합니다. 귀하는 이전 복구에서 특정 시점 복구를 수행했습니다. 원래 데이터베이스 기록에 생성되었습니다.

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

새로운 타임라인이 생성될 때마다포스트그레SQL생성"타임라인 기록"어떤 파일인지 보여주는 파일 타임라인은 언제부터 분기되었는지. 이 기록 파일은 시스템이 올바른 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 : 문서 : 9기본 백업이 수행되는 동안 명령이 실행됩니다. 가져온 다음 템플릿 데이터베이스를 가져옵니다.데이터베이스 생성복사된 내용이 수정됨 기본 백업이 진행되는 동안에도 가능합니다. 복구로 인해 이러한 수정이 발생하게 됩니다. 생성된 데이터베이스에도 전파됩니다. 이것은 물론 바람직하지 않습니다. 이러한 위험을 피하려면 다음을 수행하지 않는 것이 가장 좋습니다. 기지를 확보하는 동안 템플릿 데이터베이스를 수정하세요. 지원.

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

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