| PostgreSQL 8.3.3문서 | ||||
|---|---|---|---|---|
| Prev | Fast Backward | Chapter 23. 백업과 복원 | Fast Forward | Next |
PostgreSQL는 항상, 클러스터의 데이터 디렉토리 아래의pg_xlog/디렉토리 내에서선행 기입 로그(WAL)를 관리하고 있습니다. 이 로그는 데이터베이스의 데이터 파일에 행해진 모든 변경을 기술합니다. 이 로그는 주로 크래쉬시의 안전성을 목적으로 하고 있습니다. 시스템이 크래쉬 했다고 해도, 마지막 체크 포인트 이후에 작성된 로그 항목을"다시 실행"하는 것으로, 데이터베이스를 일관성을 유지한 상태로 복원 할 수 있습니다. 그러나 이 존재하는 로그 파일을 사용해, 데이터베이스의 백업용의 제3의 전략이 가능하게 되었습니다. 파일 시스템 레벨의 백업과 WAL 파일의 백업을 조합한다고 하는 전략입니다. 복구가 필요하다면, 백업을 복원하여, 그 후에 백업 된 WAL 파일을 다시 실행하는 것으로, 현재시점으로 백업을 가져올 수 있습니다. 관리자에게 있어서 이 방법은 지금까지 설명한 방법보다 꽤 복잡하게 되지만, 다음과 같은 큰 이점이 다수 있습니다.
시작시점의 백업과 완전하게 일치 할 필요는 없습니다. 그 백업내의 내부적인 불일치는 로그의 재시도에 의해 수정됩니다 (이는 크래쉬로부터의 복구시에 행해지는 것과 큰 차이는 없습니다). 그러므로, 파일 시스템의 snapshot 기능을 필요로 하지 않습니다. 단지tar등의 어카이브툴이 필요합니다.
WAL 파일의 줄을 수에 제한없이 늘어 놓아 다시 실행 할 수 있기 때문에, 단지 WAL 파일의 보관을 계속하는 것으로 연속적으로 백업을 할 수 있습니다. 이는 빈번하게 완전한 백업을 실시하는 것이 곤란한 대규모 데이터베이스에서 특히 가치가 있습니다.
WAL 항목의 재시도를 끝까지 실시하지 않으면 안 된다는 것은 아닙니다. 재시도를 임의의 시점까지로 정지할 수가 있어 그것에 의해, 그 시점까지의 데이터베이스의 일관성을 가진 스냅샷을 얻을 수 있습니다. 이러한 기술이포인트-인-타임 복구(시점복구)를 보조하는 것이어서, 이 전에 백업을 실행했던 임의의 시점 상태에 데이터베이스를 복원 하는 것이 가능하게 됩니다.
연속적으로 일련의 WAL 파일들을 동일한 기본 백업을 로드하고 있는 다른 머신에 입력하는 한다면, "warm standby"시스템을 보유할 수 있습니다. 즉, 임의의 시점에서 그 2번째의 머신을 거의 현시점의 데이터베이스의 복제를 가진 상태로 유효하게 할 수 있습니다.
보통의 파일 시스템 백업 기술의 경우와 같이, 이 방법은 일부에서가 아닌 데이터베이스 클러스터 전체의 복원 처리만을 지원할 수 있습니다. 또한, 보관용으로 대량의 저장 영역을 필요로 합니다. 기본 백업은 부피가 커지는 경우와 고부하인 시스템에서는 보관해야 하는 WAL의 유량(소통량)을 메가바이트 단위로 생성합니다. 그럼에도 불구하고 이것은 고신뢰성이 필요한 많은 상황들에서 선호되는 백업 기술입니다.
계속적 어카이브(많은 데이터베이스 vender들에 의해"온라인 백업"이라고도 불립니다)를 사용해 복구를 성공시키기 위해서는 적어도 백업의 시작시점까지 거슬러 올라가는 저장된 WAL 파일들의 계속적인 배열이 필요합니다. 그러므로, 운용하기 위해서는 최초의 기본 백업을 취득하기 전 에 WAL 파일을 보관하는 순서를 설정해 시험해야 합니다. 따라서, 우선 WAL 파일의 보관 구조에 대해 설명합니다.
이론상, PostgreSQL시스템의 가동에 의해, 불명확하게 WAL 기록의 줄이 생성됩니다. 시스템은 물리적으로 이 줄을, 보통 각각 16 메가바이트(이 세그먼트 크기는 PostgreSQL의 구축시로 변경 가능합니다)의, WAL세그먼트(segment) 파일에 분할합니다. 이 세그먼트(segment) 파일에는 개념적인 WAL의 줄내의 위치를 반영한, 숫자로 된 이름이 부여됩니다. WAL 보관을 실시하지 않는 경우, 시스템은 보통 몇 개의 세그먼트(segment) 파일을 생성해, 불필요해진 세그먼트(segment) 파일의 이름을 보다 큰 세그먼트(segment) 번호로 변경하는 것으로 그것을"재실행"합니다. 직전의 체크 포인트보다 전의 내용을 가지는 세그먼트(segment) 파일은 사용되지 않으면 재실행된다고 가정됩니다.
WAL 데이터를 보관하는 경우, 완성한 세그먼트(segment) 파일의 각각의 내용을 꺼내, 재이용을 위해서 회수되기 전에 그 데이터를 어디엔가 보존하는 것이 필요합니다. 어플리케이션과 이용할 수 있는 하드웨어에 따라 다르지만, "데이터를 어디엔가 보존하는 "수 많은 방법이 있습니다. 예를 들면, NFS로 마운트한 다른 머신의 디렉토리에 세그먼트(segment) 파일을 카피하는 것, 혹은 테이프 장치에 써내는 것(원래의 파일명을 식별하는 수단이 있는 것을 확인해 주십시요), 그것들을 한 번에 정리해 CD에 굽는 것, 그 외 완전히 다른 방법 등입니다. 할 수 있는 한 높은 유연성을 데이터베이스 관리자에게 제공하기 위해서, PostgreSQL는 어떻게 보관이 이루어졌는지 부터 일절 추정하지 않게 되어 있습니다. 그 대신에PostgreSQL는 관리자에게 완전한 세그먼트(segment) 파일을 어딘가 필요한 장소에 카피하는 쉘 명령을 지정시킵니다. 이 명령은 단순한cp에서도 상관하지않고, 복잡한 셸 스크립트를 호출해도 상관하지 않습니다. 모두 관리자에게 맡기고 있습니다.
archive_command 구성 파라미터로 사용하는 쉘 커맨드를 지정합니다. 실행하려면, 이러한 설정을 postgresql.conf 파일에 항상 둡니다. 이 문자열 내의 모든 %p는 보관하는 파일의 경로명에 바뀌게 되어%f는 모두 파일명 부분에만 바뀌게 됩니다. (경로명은 서버의 현재의 작업용 디렉토리 즉, 클러스터의 데이터 디렉토리로부터 봐서 상대적인 것입니다. ) 커맨드내에%문자 자체를 묻을 필요가 있으면%%라고 기술해 주십시요. 가장 간단해 자주 사용되는 커맨드는 아래와 같은 것이 됩니다.
archive_command = 'cp -i %p /mnt/server/archivedir/%f </dev/null'
이는 보관 가능한 WAL 세그먼트(segment)를/mnt/server/archivedir디렉토리에 카피합니다 (이것은 일례입니다. 추천 되는 것이 아니며, 모든 플랫폼에서 동작하지 않을 가능성이 있습니다).
이 보관용 커맨드는 PostgreSQL서버를 가동시키는 유저와 같은 소유권으로 실행됩니다. 보관되는 일련의 WAL 파일에는 사실상 데이터베이스 내의 모든 것이 포함되어 있기 때문에, 보관한 데이터를 엿보는 것으로부터 확실히 보호해야 할 것입니다. 예를 들면, 그룹이나 전원이 읽어들일 수 없는 디렉토리에 데이터를 보관해 주십시요.
보관용 커맨드가 성공했을 경우에만 제로라고 하는 종료 스테이터스를 돌려주는 것은 중요합니다. PostgreSQL는 제로라고 하는 결과에 근거해, WAL 세그먼트(segment) 파일의 보관이 성공한 것을 가정해, 그 파일을 삭제하거나 회수할지도 모릅니다. 그러나 비제로의 스테이터스는 PostgreSQL에 대해서 파일이 보관되지 않았던 것을 통지해, 성공할 때까지 주기적으로 재시행시킵니다.
보통 보관용 커맨드는 기존의 보관이 끝난 파일의 덧쓰기를 실시하지 않게 설계 되어야만 합니다. 이는 관리자의 미스(예를 들면 2개의 서로 다른 서버의 출력을 동일한 보관용 디렉토리에 송신해 버리는 등)라고 했을 경우로부터 보관 상황의 일관성을 보호하기 위한 안전책으로서 중요합니다. 실제로 기존의 파일을 덧쓰기하지 않는 한편, 그 경우에 비제로의 스테이터스를 돌려주는 것 을 확인하기 위해서 사용하는 보관용 커맨드를 시험하는 것을 권합니다. 일부의 플랫폼에서는 cp -i가 이것을 올바르게 실시하는 것, 다른 플랫폼에서는 행해지지 않는 것을 알고 있습니다. 선택한 커맨드만으로는 이러한 상황을 올바르게 취급할 수 없을 경우에는 보관이 끝난 파일이 어떤가를 검사하는 커맨드를 추가해야 합니다. 예를 들면, 이하와 같은 커맨드는
archive_command = 'test ! -f .../%f && cp %p .../%f'
대부분의 Unix계의 플랫폼에서 올바르게 동작합니다.
보관 설정을 설계할 때는 조작자의 개입이 필요하거나 보관 장소 용량 부족의 이유로 보관용 커맨드가 반복해 실패했을 때를 고려해 주십시요. 예를 들면, 자동 교환 기능이 없는 테이프에 입력하는 경우에 발생할 가능성이 있습니다. 테이프가 가득차게 되었을 경우, 테이프를 교환할 때까지 보관을 실시할 수가 없게 됩니다. 이러한 상황을 비교적 빨리 해소할 수 있도록, 적절하게 조작자에게 에러나 요구를 확실히 연락하도록 해야합니다. 이 상황이 해소할 때까지, WAL 세그먼트(segment) 파일은pg_xlog/디렉토리 내에 계속해서 채워지게 됩니다.
서버의 WAL 데이터의 생성에 필요한 평균 속도를 따라 잡고 있는 한, 보관용 커맨드의 처리 속도는 중요하지는 않습니다. 보관 프로세스가 다소 늦었다고 해도 일반적인 조작은 계속됩니다. 보관 처리가 눈에 띄게 늦어지게 되면, 재해시에 손실되는 데이터의 양이 증가하게 됩니다. 또한, 이것은pg_xlog/디렉토리 내에서 보관 처리를 기다리는 많은 세그먼트(segment)파일들이 채워지게되어 디스크 용량이 부족해지는 상황이 발생한다는 것을 의미합니다. 보관 처리가 확실히 의도 대로 동작하고 있는지 점검할 것을 추천합니다.
보관용 커맨드를 작성할 때, 보관되는 파일명은 최장 64 문자까지로, ASCII 문자와 숫자와 점의 어떤 편성을 사용해도 괜찮습니다. 원래의 상대 경로(%p)를 기억할 필요는 없지만, 파일명(%f)을 기억할 필요는 있습니다.
WAL 보관에 의해PostgreSQL데이터베이스에서 이루어진 변경은 모두 복구할 수 있지만, 설정 파일은 SQL 조작이 아닌 수동으로 변경되기 때문에, 설정 파일(postgresql.conf, pg_hba.conf, 및 pg_ident.conf)의 변경까지 복구하지 않는 것을 주의해 주십시요. 보통의 파일 시스템 백업 수속으로 백업 되는 장소로 설정 파일을 보관하고 싶은 경우가 있습니다. 설정 파일의 설치 장소를 변경하려면Section 17.2를 참조해 주십시요.
어카이브 커맨드는 완전한 WAL 세그먼트(segment)에 대해서만 불려 갑니다. 이 때문에 서버는 작은 양의 WAL 트래픽을 생성한다면(또는 처리를 방치하는 기간을 가짐), 트랜잭션의 완료와 어카이브 저장의 안전한 기록 사이에 장시간의 연기가 있을 수 있게 됩니다. 오래된 어카이브되지 않은 데이터에 제한을 두기 위해서 archive_timeout를 설정해, 강제적으로 서버를 새로운 WAL 세그먼트 파일에 있는 정도의 간격으로 바꾸도록 할 수 있습니다. 강제 변환에 의해 일찍 끝난 어카이브 파일은 완전하게 완료한 파일과 같은 크기를 가지는 것에 주의해 주십시요. 그 때문에, 매우 작은archive_timeout를 사용하는 것은 추천하지 않습니다. 저장 영역을 팽창시켜 버립니다. 보통이라면 분 단위의archive_timeout설정이 합리적입니다.
방금 끝난 트랜잭션을 즉시 어케이브하고 싶은 경우, pg_switch_xlog를 사용해 수동으로 세그먼트(segment) 변환을 강요할 수 있습니다.
다른 WAL 관리에 관련한 유틸리티 함수는Table 9-47에 열거합니다.
기본 백업의 작성 순서는 비교적 간단합니다.
WAL 보관이 유효하고, 정상적으로 동작하는 것을 확인해 주십시요.
데이터베이스에 슈퍼 유저로서 접속해, 이하의 커맨드를 실시해 주십시요.
SELECT pg_start_backup('label');
여기서label는 백업 조작을 유일하게 식별하기 위해 사용하는 임의의 문자열입니다
(추천 방법은 저장처의 백업 덤프 파일의 완전 경로를 사용하는 것입니다).
pg_start_backup는 백업 정보를 가지는 backup_label라는 이름의백업 라벨파일을, 클러스터 디렉토리 내에 작성합니다.
이 커맨드를 실행했을 때 클러스터 내의 어느 데이터베이스에 접속했는지 주의할 필요는 없습니다. 이 함수의 반환 결과는 무시할 수 있지만, 에러가 발생했을 경우는 작업을 진행시키기 전에 처리해 주십시요.
tar나 cpio와 같은 익숙한 임의의 파일 시스템 백업 툴을 사용해, 백업을 실행해 주십시요. 이 작업시에, 데이터베이스의 일반 연산을 정지할 필요는 없으며, 바람직한 방법도 아닙니다.
다시 슈퍼유저로 데이터베이스에 접속해, 이하의 커맨드를 실행해 주십시요.
SELECT pg_stop_backup();
이것은 백업 모드를 종료하고, 다음의 WAL 세그먼트에의 자동 전환을 실시합니다. 이 변환의 이유는 백업 기간 중에 쓰여진 마지막 WAL 파일을 곧바로 보관할 수 있도록 준비하는 것입니다.
백업 기간중에 사용된 WAL 세그먼트 파일이 보관되면, 처리할 일은 끝납니다.
pg_stop_backup의 결과로 식별되는 파일은 백업을 종료시키기 위해서 보관해야 하는 마지막 세그먼트입니다.
벌써archive_command를 설정했기 때문에, 이러한 파일의 보관은 자동으로 발생합니다.
많은 경우 빠르게 진행해지지만, 백업의 완료를 확인할 수 있도록 보관 시스템을 감시하여 진행된 것을 확인하도록 권합니다.
사용하고자 하는 일부 백업 툴은 복사하고 있는 도중에 파일이 변경된다는 것을 경고하거나 에러를 보고할지 모릅니다. 이 상황은 정상적인 것으로, 가동하고 있는 데이터베이스의 기본 백업을 가지고 있는 경우는 에러가 아닙니다. 그러니까, 이런 종류의 경고와 진짜 에러를 구별할 수 있어야 합니다. 예를 들면, rsync의 버전에 따라서 "사라진 원시파일"에 대해서 다른 종료 코드를 반환하고, 이 종료 코드를 에러가 아니면 받아들이는 하는 드라이버 스크립트를 기술할 수 있습니다. 또한, 일부 GNUtar버전은, tar가 복사하고 있는 동안에 파일이 절단되면, 치명적인 에러를 구분할 수 없는 에러코드를 반환합니다. 다행히도, 만약 파일이 백업동안 변경되거나 그 외의 에러로 2이라면, GNUtar버전 1.16과 1를 가지고 프로그램을 종료합니다.
pg_start_backup로부터 실제의 백업의 시작때까지의 경과시간이나 백업의 종료시각으로부터pg_stop_backup까지의 경과시간을 특별히 신경쓸 필요는 없습니다.
몇분의 지연은 아무런 문제 없습니다.
(그러나 보통full_page_writes를 사용할 수 없는 서버를 실행하는 경우, 백업 모드에서는 full_page_writes가 강요되기 때문에,
pg_start_backup로부터pg_stop_backup까지의 사이의 성능 저하를 발견할 것입니다. )
그러나 이러한 단계를 겹치지 않게 차례대로 수행하도록 주의할 필요가 있습니다.
그렇지 않으면, 백업이 엉망이 됩니다.
백업 덤프에, 데이터베이스 클러스터 디렉토리(예를 들면/usr/local/pgsql/data) 이하에 있는 모든 파일이 포함되어있는지 확인해 주십시요. 이 디렉토리 이하에 존재하지 않는 테이블 공간을 사용하는 경우, 이들을 포함시키는 것을 주의하십시요. (그리고 백업 덤프가 링크로서 기호 연결을 어케이브된 것을 확인해 주십시요. 그렇지 않으면 복구 작업은 테이블 공간을 엉망으로 만들어 버립니다).
그러나 클러스터 디렉토리의pg_xlog/하위 디렉토리에 있는 파일을 백업 덤프로부터 생략할 수 있습니다. 이것은 다소 복잡하지만, 복구 작업 중의 실패의 위험을 줄일 수 있기 때문에, 가치가 있습니다. pg_xlog/가 클러스터 디렉토리 외의 다른 곳을 지시하는 기호 연결의 경우, 지정하는 것이 간단합니다. 이것은 성능상의 이유로 자주 사용되는 설정입니다.
이 백업을 사용하고 싶을 경우, 백업의 실행 기간과 이후에 생성된 모든 WAL 세그먼트 파일을 가지고 있어야 합니다.
이를 돕기 위해, pg_stop_backup함수는 백업 이력 파일을 생성해, WAL 보관 영역에 보존합니다.
이 파일은 백업을 사용하기 위해 만들어야 하는 최초의 WAL 세그먼트 파일의 이름을 따릅니다.
예를 들면, 최초의 WAL 파일이 0000000100001234000055CD의 경우, 백업 이력 파일은0000000100001234000055CD. 007C9330.backup 이름이 됩니다.
(이 파일명의 2번째의 번호는 WAL 파일내의 정확한 위치를 나타내고, 이것은 보통 무시될 수 없습니다. )
백업 기간(백업 이력 파일로 지정된 것처럼)에 사용된, 파일 시스템 백업과 WAL 세그먼트 파일을 안전하게 보관한 후,
수치적으로 작은 이름의 WAL 세그먼트는 파일 시스템 백업의 복구에 더이상 필요하지 않으므로 삭제할 수 있습니다.
그러나 데이터를 복구를 완전히 보증하기 위해, 몇 개의 백업 세트의 보존을 검토해야합니다.
백업 이력 파일은 작은 텍스트 파일입니다.
거기에는 pg_start_backup에게 보낸 라벨 문자열 뿐 아니라, 백업 시작와 종료의 시각과 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 파일과 관련해서 얼마나 되돌려야 하는지를 스스로 남겨야 합니다.
보통은 위의 계속적 어카이브 순서를 따르도록 권합니다.
만약 최악의 사태가 발생하고, 백업으로부터 복구할 필요가 있다면 이하에 그 순서를 설명합니다.
서버가 실행 중이라면, 정지시켜 주십시요.
사용할 용량을 가지고 있다면, 나중에 필요한 경우를 대비해 클러스터 데이터 디렉토리 전체와 테이블 공간을 모두 카피해 주십시요. 이러한 조치는 기존의 데이터베이스를 2개 보관할 수 있는 충분히 비어있는 공간을 필요로 합니다. 충분한 공간이 없는 경우, 적어도 클러스터 데이터 디렉토리 이하의 pg_xlog디렉토리의 내용만은 복사해야 합니다. 여기에는 시스템이 정지하기 전에 보관되지 않은 로그 파일이 포함될 수 있기 때문입니다.
클러스터 데이터 디렉토리 이하, 및 사용 중인 테이블 공간의 root 디렉토리 이하에 있는 기존의 모든 파일과 하위디렉토리를 삭제해 주십시요.
백업 덤프로부터 데이터베이스 파일을 복구해 주십시요. 파일이 올바른 소유권(root가 아닌 데이터베이스 시스템 유저입니다! )으로 복구되고 있는 지 확인해 주십시요. 테이블 공간을 사용하고 있는 경는 pg_tblspc/내의 기호 연결이 정확히 복구되고 있는 지 점검할 필요가 있습니다.
pg_xlog/내에 있는 파일을 모두 삭제해 주십시요. 이것들은 백업 덤프로부터 생성되어, 현재의 것보다 오래되었습니다. pg_xlog/를 전혀 보관하고 있지 않으면, 다시 작성해 주십시요. 그리고 pg_xlog/archive_status/ 하위 디렉토리도 확실하게 재작성해 주십시요.
단계 2로 저장시킨 보관되지 않은 WAL 세그먼트 파일이 있다면, pg_xlog/에 카피해 주십시요 (이들을 이동시키는 것이 아닌 복사하는 것이 최선입니다. 이는 문제가 발생하거나 다시 실행해야하는 경우, 여전히 변경되지 않은 파일을 가지고 있을 수 있습니다.)
복구 커맨드 파일recovery.conf(Recovery Settings를 참조)를 클러스터 데이터 디렉토리에 작성해 주십시요. 또한, 일시적으로pg_hba.conf를 편집해, 복구 완료를 확인할 수 있을 때까지 일반 유저가 접속할 수 없도록 합니다.
서버를 시작시켜 주십시요. 서버는 복구 모드에 들어가, 필요한 보관이 끝난 WAL 파일군의 read를 실시합니다. 외부적인 에러에 의해 복구가 중단하면, 서버를 재시작시키고, 복구 처리를 계속해 주십시요. 복구 처리가 완료하면, (우연히 크래쉬되어도 재차 복구 모드에 들어가지 않게) postmaster는 recovery.conf의 이름을recovery.done로 변경합니다. 그 후 일반적인 데이터베이스 조작을 시작합니다.
데이터베이스 내용을 검사해, 원하는 시점까지 복구되었는지 확인해 주십시요. 복구되지 않은 경우, 단계 1로 돌아가십시요. 문제가 없으면, 유저가 사용할 수 있도록pg_hba.conf를 정상 상태로 되돌려 주십시요.
여기서 중요한 것은 복구 커맨드 파일을 설정하는 것입니다. 이 파일에서 어떻게 복구싶은 지와 어디까지 복구하고 싶은 지를 기술합니다. recovery.conf.sample(보통은 Installation의 share/디렉토리에 저장됨)를 표본으로 사용할 수 있습니다. recovery.conf에 무조건 지정해야 하는 것은 보관된 WAL 파일 세그먼트를 어떻게 되돌릴까를PostgreSQL에 통지하는 restore_command입니다. archive_command같이, 이것은 쉘 커맨드 문자열입니다. 여기에는 대상의 로그 파일의 이름으로 치환되는 %f나 로그 파일의 복사된 경로를 나타내는 %p를 포함할 수 있습니다. (경로명은 현재의 작업용 디렉토리, 즉, 클러스터의 데이터 디렉토리에서 본 상대 경로입니다. ) 커맨드 내에%문자 자체를 넣어야 한다면, %%라고 기재해 주십시요. 간단하고 유용한 커맨드는 이하와 같습니다.
restore_command = 'cp /mnt/server/archivedir/%f %p'
이것은 사전에 보관된 WAL 세그먼트를 /mnt/server/archivedir디렉토리로부터 카피합니다. 당연히, 좀 더 복잡한 것 사용할 수 있습니다. 예를 들면, 연산자에게 적절한 테이프를 사용 가능하도록 요구하는 셸 스크립트도 가능합니다.
이 커맨드가 실패했을 때 nonzero 종료 상태를 반환하는 것은 중요합니다. 이 커맨드는 보관 장소에 존재하지 않는 로그 파일을 요청 할 지도 모릅니다. 이러한 경우, 요청을 받으면 nonzero 를 리턴해야만 합니다. 이것은 에러 상태가 아닙니다. 또한, %p의 파일명 부분은%f과 다르다는 것을 주의하십시요. 그러므로, 이들이 서로 교환가능할 것이라고 예상하지 마십시요.
어케이브에서 발견되지 않았던 WAL 세그먼트는 pg_xlog/로부터 검색됩니다. 이로 인해, 최근의 보관 하지 않은 세그먼트를 사용할 수 있습니다. 그러나 어케이브에서 사용가능한 세그먼트는 pg_xlog/ 의 파일보다 우선적으로 사용할 수 있습니다. 시스템은 보관된 파일을 꺼낼 때 기존의 pg_xlog/의 내용을 겹쳐 쓰지 않습니다.
일반적으로, 모든 이용가능한 WAL 세그먼트를 사용해 복구 처리를 합니다. 그로 인해, 데이터베이스를 현시점까지(혹은 이용 가능한 WAL 세그먼트를 가질 수 있는 가까운 시점까지) 복구합니다. 그러나, 이전의 시간에서 복구하기를 원한다면(즉, 소규모 DBA에서 주 트랜잭션 테이블을 삭제하기 바로 전), recovery.conf에 원하는 정지 시점을 기술할 수 있습니다. 특정한 트랜잭션 ID의 완료나 날짜/시간을 "recovery target"로 정지 시점을 기술할 수 있습니다. 사용하기 위한 트랜잭션 ID의 정확성을 식별하는 것을 돕는 툴이 없기 때문에, 현재 날짜/시간 입력 옵션은 매우 유용합니다.
Note: 정지시점은 백업의 종료시각보다 뒤어야 합니다.(
pg_stop_backup) 백업이 사용 중일 경우, 시간을 복구하는 기본 백업은 사용할 수 없습니다. (이러한 시점까지 복구하려면, 이전 기본 백업으로 돌아가, 거기서부터 롤 forward 해주십시요.)
복구시에 WAL 데이터의 파손을 알 수 있으면, 그 시점까지의 복구를 실시하지만, 서버를 실행시키지 않습니다. 이러한 경우, "복구 대상"으로 파손 시점보다 전의 시점을 지정하여 복구 처리를 정상적으로 완료할 수 있도록 복구 프로세스를 처음부터 다시 할 수 있습니다. 시스템 크래쉬와 같은 외적 이유로 복구 처리가 실패했거나 WAL 어카이브가 액세스할 수 없게 되었을 경우, 복구 처리를 재시작시킬 수 있습니다. 이 경우는 실패한 시점과 거의 같은 곳부터 시작합니다. 복구 처리의 재시작은 다음과 같은 보통 조작시의 체크 포인트 처리와 같이 동작합니다. 서버는 정기적으로 모든 상태를 디스크에 강요하고, 재차 스캔할 필요가 없는 이미 처리된 WAL 데이터를 나타내는 pg_control파일을 업데이트합니다.
이하의 설정은 recovery.conf에서만 설정 가능하고, 복구 기간에만 적용됩니다. 이는 후에 실행하는 복구마다 재설정해야 합니다. 복구가 시작되면 변경할 수 없습니다.
WAL 파일 세트의 보관된 세그먼트를 꺼내기 위해서 실행하는 쉘 커맨드입니다. 이 파라미터는 필수입니다. 문자열 중 %f는 모두 보관 장소에서 꺼내는 파일명으로 대체할 수 있으며, %p는 모두 서버 상의 카피처의 경로명으으로 대체될 수 있습니다. (경로명은 현재 작업하는 디렉토리 즉, 클러스터의 데이터 디렉토리로부터 본 상대 경로입니다. ) 커맨드에 실제%문자를 포함시키기 위해 %%를 입력하십시요.
이 커맨드로 중요한 점은 성공했을 경우만 0 종료 상태를 돌려주는 것입니다. 이 커맨드는 보관 장소에 존재하지 않는 파일명을 요청 할 수 있습니다. . 요청이 있는 경우는 nonzero를 반환해야만 합니다. 이하에 예를 들면,
restore_command = 'cp /mnt/server/archivedir/%f "%p"' restore_command = 'copy /mnt/server/archivedir/%f "%p"' # Windows
이 파라미터는 복구 처리를 어디까지 실시하는지를 나타내기 위해 타임 스탬프를 지정합니다. 많아도 1개의recovery_target_time와 recovery_target_xid를 지정할 수 있습니다. 디폴트에서는 WAL 로그의 마지막까지 복구 합니다. 또한, 정확한 정지시점은recovery_target_inclusive에 의해 바뀝니다.
이 파라미터는 복구 처리를 어디까지 진행하는지를 나타내는 트랜잭션 ID를 지정합니다. 트랜잭션 ID는 트랜잭션의 시작시에 차례로 할당할 수 있지만, 트랜잭션의 종료는 이러한 차례대로 일어나지 않다는 것을 주의하십시요. 복구되는 트랜잭션는 지정한 ID보다 전에 처리된 트랜잭션입니다(옵션으로 지정한 ID를 포함할 수도 있습니다). 많아도 1개의 recovery_target_xid과 recovery_target_time를 지정할 수 있습니다. 디폴트에서는 WAL 로그의 마지막까지 복구 합니다. 또한, 정확한 정지시점은recovery_target_inclusive에 의해 바뀝니다.
지정된 복구 대상 직후에 정지할 것(true)인가, 복구 대상 직전에 정지할(false)것인지를 지정합니다. 이러한 복구는 지정된 recovery_target_time와 recovery_target_xid에 적용됩니다. 이는 대상 처리 시각이나 ID에 정확히 일치하는 트랜잭션를 복구에 포함할지를 나타냅니다. 디폴트는 true입니다.
특정한 시계열로 복구를 실시하는지를 지정합니다. 디폴트는 기본 백업을 취득한 시점과 같은 시계열에 따라 복구 합니다. 이 파라미터는 point-in-time 복구 뒤에 상태로 반환해야 하는 복잡한 재복구에만 설정할 필요가 있습니다. 자세한 사항은 Section 23.3.4을 참조해 주십시요.
과거의 시점까지 데이터베이스를 복구할 수 있는 기능은 SF의 시간 여행이나 패러렐 유니버스 같은 다소 복잡합이 있습니다. 예를 들면, 데이터베이스의 원래의 이력으로, 화요일의 저녁 5:15 PM에 중요한 테이블을 삭제해, 수요일의 점심까지 착오를 알아차리지 않았다고 합니다. 당황하지 않고, 백업을 통해 화요일 저녁 5:14 PM 시점에 복구를 하고 데이터베이스를 실행시킵니다. 데이터베이스 세계의 이러한 이력에서는, 그 테이블을 결코 삭제할 수 없습니다. 그러나 시간이 흐른 후, 결국 이것은 굉장한 문제는 아니었다는 것을 알았다고 가정하면, 원래의 이력의 이 후로 시점을 돌리기를 원할 것입니다. 데이터베이스는 이미 실행되고 있기 때문에, 일련의 WAL 세그먼트 파일의 일부는 겹쳐쓰는 것이 가능하지 않을 것입니다. 이 경우, 돌리고 싶은 시점보다 미래의 시점을 원하기 때문에, 되돌릴 수 없습니다. 그러므로, point-in-time 복구시킨 후에 생성된 일련의 WAL 기록과 원래 데이터베이스의 이력에 대해 생성된 WAL 기록을 구별할 필요가 있습니다.
이러한 문제를 다루기 위해 PostgreSQL에는 시계열이라고 하는 개념이 있습니다. 어카이브 복구가 완료했을 때는 언제라도, 그 복구 후에 생성된 WAL 기록을 식별하기 위한 새로운 시계열이 생성됩니다. 시계열 ID번호는 WAL 세그먼트 파일명의 일부입니다. 그러므로, 새로운 시계열은 지금까지의 시계열로 생성된 WAL 데이터를 겹쳐 쓰지 않습니다. 실제, 많은 다른 시계열을 보관할 수 있습니다. 불필요한 기능이라고 생각할지도 모릅니다만, 구원해주는 일이 자주 있습니다. 어느 시점까지 복구 할지 확실치 않은 상황을 생각해 보세요. 그 때는 과거의 이력의 분기점으에서 최선의 시점을 찾아내기 위해서, 여러번의 시행착오를 거쳐 point-in-time 복구를 실시해야 합니다. 시계열이 없으면 이러한 절차는 곧바로 관리 불능의 혼란을 불러일으킵니다. 시계열을 사용해, 다음에 중단했을 때 계열 분기의 상태를 포함한, 과거의 임의 상태를 복구시킬 수 있습니다.
새로운 시계열이 생성될 때, PostgreSQL는 어느 시계열이 언제 어디에서 분기 했는지를 나타내는 "시계열 이력"파일을 작성합니다. 이 이력 파일은 복수의 시계열을 포함한 어케이브로부터 복구할 때 시스템이 올바른 WAL 세그먼트 파일을 선택할 수 있도록 하기 위해 필요합니다. 따라서, 이력 파일은 WAL 세그먼트 파일과 같이 WAL 보관 영역에 보관됩니다. 이력 파일은(거대한 세그먼트 파일과는 달리) 단순한 작은 텍스트 파일이므로, 저렴하고 적당하게 무기으로 보관할 수 있습니다. 필요하면, 이력 파일에 코멘트를 추가해, 이 특정한 시계열이 어떻게, 왜 생성되었는지를 표시해 독자적인 주석을 부여할 수 있습니다. 특히 이러한 코멘트는 실험의 결과 얼마든지의 시계열의 티켓이 있는 경우에 유용합니다.
복구 처리의 디폴트는 기본 백업이 취득된 시점의 시계열과 동일한 시계열에 따른 복구입니다. 일부 자식 시계열로 복구하고 싶은(즉, 복구 시행 이후에 생성된 있는 상태에 돌아오고 싶다) 경우는 recovery.conf로 대상의 시계열 ID를 지정해야 합니다. 기본 백업보다 전에 분기했을 경우, 시계열에 따라 복구할 수 없습니다.
본 문서 작성 시점에서는 계속적 어카이브 기술에 몇 개의 제한이 있습니다. 향후 릴리스에서는 수정될 것입니다.
해시 인덱스에 대한 조작은 현재 WAL 로그에 남지 않습니다. 따라서, 다시 실행해도 이러한 인덱스는 업데이트되지 않습니다. 추천되는 보안책으로 복구 연산이 완료된 후 수동으로 인덱스 각각 대해 REINDEX 를 실시하는 것입니다.
만약 기본 백업을 실행 되었을 때, CREATE DATABASE 커맨드가 실행되고, 기본 백업이 처리되는 동안 CREATE DATABASE가 카피하고 있는 template 데이터베이스가 변경되면, 복구는 작성된 데이터베이스로 이렇나 변경을 전파하는 원인이 됩니다. 물론, 이것은 바람직하는 일이 아닙니다. 이 위험을 회피하려면, 기본 백업 기간 중에 모든 template 데이터베이스를 변경하지 않는 것이 제일입니다.
CREATE TABLESPACE 커맨드는 리터럴의 절대 경로로 WAL에 로그가 기록되고, 같은 절대 경로에서의 테이블 공간이 생성될 때 재실행됩니다. 이는 만약 로그가 다른 머신상에서 재생되는 경우에는 바람직하지는 않습니다. 로그 재생이 비록 동일한 머신이어도, 신규의 데이터 디렉토리이면 위험합니다. 왜냐하면, 재생은 원래의 테이블 공간 내용을 계속 겹쳐 쓰기 때문입니다. 이런 종류의 잠재적 행동을 막기 위해서는 테이블 공간을 작성하거나 삭제 후, 새로운 기본 백업을 실시하는 것이 최선입니다.
또한, 디폴트의WAL포맷은 수많은 디스크 페이지의 스냅샷을 포함하고 있기 때문에, 부피가 커지는 것에 주의하십시요. 이러한 페이지 snapshot는 크래쉬로부터 복구을 위해 설계되고 있습니다. 부분적으로 입력되는 디스크 페이지를 수정해야 할 필요가 있기 때문입니다. 시스템의 하드웨어나 소프트웨어에 따라서는 부분적인 디스크 페이지의 입력은 무시해도 괜찮을 만큼 작습니다. 이 경우full_page_writes파라미터를 사용해 페이지 스냅샷을 무효로 하여, 어카이브된 로그의 총용량을 큰폭으로 축소할 수 있습니다 (실제로 설정을 실시하기 전에, Chapter 27의 주의 사항과 경고를 읽어 주세요). 페이지 스냅샷을 무효로 해도 PITR 연산을 로그에 사용할 수 없도록 막는 것은 아닙니다. 향후 과제는 full_page_writes가 작동되는 경우라도 불필요한 페이지를 없애고 보관된 WAL 데이터의 압축을 실시하는 것입니다. 당장 관리자는 가능한 한 체크 포인트 간격 파라미터를 크게 함으로써, WAL에 포함되는 페이지 snapshot의 수를 줄일 수 있습니다.