| PostgreSQL 8.3.3문서 | ||||
|---|---|---|---|---|
| Prev | Fast Backward | Chapter 23. 백업과 복원 | Fast Forward | Next |
이 덤프 방법은 SQL명령으로 텍스트 파일을 생성해, 그 파일을 서버가 재차 실행했을 때, 덤프한 시점과 같은 상태가 재구축 되도록 하는 것입니다. 이러한 목적으로, PostgreSQL는 pg_dump유틸리티 프로그램을 제공하고 있습니다. 이 명령의 기본 사용법은 다음과 같습니다.
pg_dump dbname > outfile
보시는 바와 같이, pg_dump는 결과를 표준 출력에 써냅니다. 이것을 어떻게 활용할 수 있을지를 지금부터 설명합니다.
pg_dump는 PostgreSQL의 보통의 클라이언트 어플리케이션입니다 (특히, 뛰어난 기능을 발휘). 이는 데이터베이스에 접속 가능한 모든 사용자로부터 이 백업 절차를 실행할 수 있다는 것을 의미합니다. 그러나 pg_dump는 동작에 특별한 권한을 필요하지 않습니다. 특히, 백업을 실시하고자 하는 모든 테이블을 읽어들여야 하며, 실제의 작업은 대부분의 경우 데이터베이스의 관리자가 백업을 실행해야 합니다.
pg_dump를 실시하는 데이터베이스 서버를 명확히 정의하기 위해, 커맨드 라인의-h host 옵션과 -p port 옵션을 사용합니다. 디폴트 호스트는 로컬 호스트, 또는 PGHOST환경 변수로 지정한 것입니다. 마찬가지로 디폴트 포트는 PGPORT환경 변수로 지정되고 있는지, 잘 되지 않는 경우는 컴파일의 설정이 초기화가 됩니다(편리하게도, 서버는 보통 컴파일시의 설정을 디폴트로 합니다).
다른PostgreSQL의 클라이언트 응용프로그램과 같이, pg_dump는 디폴트로 operating system의 현재의 유저명과 같은 데이터베이스 유저명으로 접속합니다. 이것을 변경하려면-U옵션 또는 PGUSER환경 변수를 설정합니다. pg_dump의 접속은 보통의 클라이언트 인증 매커니즘에 따른다는 것을 기억하시기 바랍니다(Chapter 20로 설명되어 있습니다).
pg_dump로 작성된 덤프는 내부적으로 일관성이 있습니다. 즉, 덤프는 pg_dump가 시작되었을 때, 데이터베이스의 snapshot 가리키고 있습니다. pg_dump의 조작은 데이터베이스에 대한 다른 작업을 방해하지 않습니다(ALTER TABLE의 형태와 같은 배타적 락이 필요한 작업은 예외입니다).
Important: 데이터베이스 스키마가 OID에 의존하고 있는 경우(예를 들면 외부 키와 같이) , pg_dump에 OID도 함께 덤프하도록 지정해야 합니다. 이것을 실시하려면-o명령 라인 옵션을 사용합니다.
pg_dump로 작성된 텍스트 파일들은psql프로그램으로 읽혀지도록 되어 있습니다. 이하에, 덤프를 복원 하는 일반적인 명령을 나타냅니다.
psql dbname < infile
여기서 infile 은pg_dump커맨드로 outfile 한 것입니다. dbname 데이터베이스는 이 커맨드에서는 작성되지 않습니다. psql를 실행하기 전에 스스로template0부터 작성해 주십시요 (예를 들면createdb -T template0 dbname 와 같이). psql는 pg_dump처럼, 접속 데이터베이스 서버와 사용하는 유저명을 명시합니다. 상세한 것에 대하여는 psql 의 레퍼런스 페이지를 참조해 주십시요.
SQL 덤프 복원을 실행하기 전에, 덤프된 데이터베이스 내 오브젝트를 소유하는 유저나 그 오브젝트에 권한이 주어진 유저가 존재해야 합니다. 존재하고 있지 않는 경우, 복구는 오브젝트 원래의 소유권이나 부여된 권한을 재작성할 수 없습니다. (이와 같은 경우도 있겠지만, 보통 그렇지 않습니다).
디폴트 psql스크립트는 SQL 에러가 일어난 후도 실행을 계속합니다. 스크립트의 상위 부분에 이하의 커맨드를 사용해 이 움직임의 변경을 실시하는 것으로, 에러가 발생했을 경우에psql가, 종료 상태 3으로 프로그램으로부터 빠지도록 할 수 있습니다.
\set ON_ERROR_STOP
어느 방법이든, 부분적으로만 복원된 덤프가 됩니다. 그 밖에, 덤프 전체를 1개의 트랜잭션으로 복원되도록 지정할 수 있습니다. 이렇게 하면, 복원이 완전하게 끝나거나 완전하게 되돌아 가게 됩니다. 이 모드는 psql의 커맨드 라인 옵션에-1 또는 --single-transaction를 기술하는 것으로 지정할 수 있습니다. 이 모드를 사용하는 경우, 몇 시간을 들여 실행하고 있던 복원이 경미한 에러로 rollback되는 것을 주의해 주십시요. 그러나 부분적으로 복원된 덤프로부터 수동으로 복잡한 데이터베이스를 정리하는 방법보다 바람직합니다.
pg_dump와 psql에서는 파이프로부터 읽고 쓰기를 할 수 있으므로, 한 서버로부터 다른 서버에 데이터베이스를 직접 덤프할 수 있습니다. 이하에 예를 들면,
pg_dump -h host1 dbname | psql -h host2 dbname
Important: pg_dump로 작성되는 덤프는 template0와 관련되어 있습니다. 즉template1를 경유해 추가된 모든 언어, 프로시저 등도 pg_dump에 의해 덤프 됩니다. 결과적으로 복원 할 때, 커스터마이즈된template1를 사용하고 있는 경우는 위의 예와 같이template0로부터 빈 데이터베이스를 작성할 필요가 있습니다.
<-- After restoring a backup, it is wise to run ANALYZE on each database so the query optimizer has useful statistics. An easy way to do this is to run vacuumdb -a -z; this is equivalent to running VACUUM ANALYZE on each database manually. For more advice on how to load large amounts of data into PostgreSQL efficiently, refer to Section 13.4. --> 백업을 복원 한 후, 쿼리 옵티마이저가 유효한 통계 정보를 사용할 수 있도록, 각 데이터베이스에 대해서 ANALYZE 를 실행 할 것을 권합니다. 이 문제 해결의 간단한 방법은 vacuumdb -a -z를 실행하는 것입니다. 이는 각 데이터베이스에 대해서VACUUM ANALYZE를 수동으로 실행하는 것과 같습니다. 효율적으로 대규모 데이터를PostgreSQL에 로드하는 방법에 관한 보다 많은 정보에 대해서는 Section 13.4을 참조해 주십시요.
pg_dump는 동시에 단일의 데이터베이스만을 덤프 합니다. 또한, 롤이나 테이블 공간에 대한 정보는 덤프 하지 않습니다. (이것들은 데이터베이스이기 보다는 클러스터 전체의 것이기 때문입니다.) 데이터베이스 클러스터의 전체 내용의 간편한 덤프를 돕기기 위해서, pg_dumpall 프로그램이 제공되고 있습니다. pg_dumpall는 지정된 클러스터의 각 데이터베이스의 백업을 실시하고, 롤이나 테이블 공간 정의 등의 클러스터 전체에 걸치는 데이터를 보존합니다. 이 커맨드의 기본적인 사용 방법은:
pg_dumpall > outfile
입니다. 덤프의 결과는 psql로 복원 될 수 있습니다.
psql -f infile postgres
(실제로, 시작시에 임의의 기존의 데이터베이스명을 지정할 수가 있지만, 빈 클러스터 내에 재로드하는 경우는 항상 postgres 를 사용해야 합니다. ) 롤이나 테이블 공간의 정보를 복원해야 하기 때문에, pg_dumpall의 덤프를 복원 할 때는 데이터베이스 슈퍼 유저(관리자)의 액세스 권한을 항상 필요로 합니다. 테이블 공간을 사용하고 있는 경우, 덤프 내의 테이블 공간의 경로가 새로운 Installation에 적절한지 여부를 확인해 주십시요.
PostgreSQL는 시스템 상에서 최대 가능한 파일 크기보다 큰 테이블을 취급할 수 있으므로, 파일에 덤프 할 때, 시스템으로 허용되고 있는 파일 크기를 넘어 버리는 문제가 발생 할 수도 있습니다. pg_dump는 표준 출력에 써내기 때문에, 이 문제를 해결하기 위해서 Unix 표준의 툴을 사용해 회피할 수 있습니다. 이것을 실시하기 위한 몇 가지 방법들:
압축 덤프의 사용. 예를 들어, 자신이 선호하는 gzip와 같은 압축 프로그램을 사용할 수 있습니다.
pg_dump dbname | gzip > filename .gz
바탕으로 되돌리려면 다음과 같이 합니다.
createdb dbname gunzip -c filename .gz | psql dbname
혹은 다음과 같이도 할 수 있습니다.
cat filename .gz | gunzip | psql dbname
split의 사용. split명령으로 산출된 결과를 사용하고 있는 파일 시스템을 받아들일 수 있는 기본크기를 분할 할 수 있습니다. 예를 들면 1 메가바이트씩 분할하려면 다음과 같이 합니다.
pg_dump dbname | split -b 1m - filename
바탕으로 되돌리려면 다음과 같이 합니다.
createdb dbname cat filename * | psql dbname
pg_dump의 커스텀 덤프 서식의 사용. 만약PostgreSQL가zlib압축 라이브러리 인스톨이 끝난 시스템 상에서 구축된 것이라면, 커스텀 덤프 서식에서는 출력 파일을 써낼 때 데이터를 압축합니다. gzip를 사용했을 때와 비슷한 덤프 크기가 되지만, 테이블의 복원을 부분적으로 실시할 수 있는 점에서 우수하다고 말할 수 있습니다. 이하의 커맨드는 커스텀 덤프 서식에서의 데이터베이스 덤프를 실행합니다:
pg_dump -Fc dbname > filename
커스텀 서식의 덤프는 psql를 위한 스크립트가 아니기 때문에, pg_restore로 대신 복원 해야 합니다. 자세한 사항은 pg_dump와 pg_restore의 레퍼런스 페이지를 참조해 주십시요.