시작했을 때 pg_dump기본 일반 형식을 사용했습니다. 나는 깨닫지 못했다.

연구에 따르면 pg_dump -Fc | gzip -9 -c > dumpfile.gz. 나는 깨달았다.

데이터베이스를 새로 만들 때가되면

# create tablespace dbname location '/SAN/dbname';
# create database dbname tablespace dbname;
# alter database dbname set temp_tablespaces = dbname;

% gunzip dumpfile.gz              # to evaluate restore time without a piped uncompression
% pg_restore -d dbname dumpfile   # into a new, empty database defined above

나는 깨닫지 못했다고 느꼈다. 복원은 데이터베이스를 만드는 데 12 시간이 걸렸다.

# select pg_size_pretty(pg_database_size('dbname'));
47 GB

이 데이터베이스가 몇 테라 바이트가 될 것이라는 예측이 있기 때문에 지금 성능 향상을 살펴 봐야합니다.

제발 계몽 해주세요.

먼저 디스크 설정에서 적절한 IO 성능을 얻고 있는지 확인하십시오. 그런 다음 PostgreSQL 설치가 적절하게 조정되었는지 확인합니다. 특히 shared_buffers올바르게 설정 maintenance_work_mem되어야하며, 복원 중에는 증가해야하며, 복원 full_page_writes중에는 꺼져 있어야하며, 복원 wal_buffers중에는 16MB checkpoint_segments로 증가해야하며, 복원 중에는 16과 같은 값으로 증가해야하며, 불합리한 로그온이 없어야합니다. (실행 된 모든 명령문 로깅과 같이) auto_vacuum복원 중에는 비활성화해야합니다.

8.4를 사용중인 경우 병렬 복원도 실험 해보고 pg_restore에 대한 --jobs 옵션을 사용합니다.

pg 덤프 및 복원 개선

PG_DUMP | 항상 형식 디렉토리 및 -j옵션 사용

time pg_dump -j 8 -Fd -f /tmp/newout.dir fsdcm_external

PG_RESTORE | postgres.conf 및 format-directory 및 -j옵션에 항상 튜닝을 사용하십시오.

work_mem = 32MB
shared_buffers = 4GB
maintenance_work_mem = 2GB
full_page_writes = off
autovacuum = off
wal_buffers = -1

time pg_restore -j 8 --format=d -C -d postgres /tmp/newout.dir/

두 가지 문제 / 아이디어 :

1. -Fc를 지정하면 pg_dump 출력이 이미 압축되어 있습니다. 압축은 최대가 아니므로 "gzip -9"를 사용하여 약간의 공간 절약을 찾을 수 있지만 백업의 -Fc 버전을 압축 및 압축 해제하는 데 사용되는 추가 시간 (및 I / O)을 보장하는 것으로는 충분하지 않습니다. .

2. PostgreSQL 8.4.x를 사용하는 경우 새로운 pg_restore 명령 줄 옵션 "-j n"을 사용하여 -Fc 백업에서 복원 속도를 높일 수 있습니다. 여기서 n은 복원에 사용할 병렬 연결 수입니다. 이렇게하면 pg_restore가 둘 이상의 테이블 데이터를로드하거나 동시에 둘 이상의 인덱스를 생성 할 수 있습니다.

데이터베이스의 주요 업그레이드가 아니라 백업이 필요하다고 가정합니다.

대형 데이터베이스의 백업을 위해 당신은 설정해야 지속적인 보관 대신을 pg_dump.

1. WAL 보관을 설정합니다 .

2. 예를 들어
   psql template1 -c "select pg_start_backup('`date + % F- % T '' 를 사용하여 매일 기본 백업을 만드십시오. ) " rsync -a --delete / var / lib / pgsql / data / / var / backups / pgsql / base / psql template1- c "pg_stop_backup () 선택"`

복원은 pg_start_backup백업 위치에서 시간이 지나지 않은 데이터베이스 및 WAL 로그를 복원 하고 Postgres를 시작 하는 것처럼 간단 합니다. 그리고 훨씬 빨라질 것입니다.

zcat dumpfile.gz | pg_restore -d db_name

현재 병목 현상 인 디스크에 압축되지 않은 데이터의 전체 쓰기를 제거합니다.

백업을 압축하면 성능이 더 빨라진다는 사실만으로 짐작할 수 있듯이 백업은 I / O 바운드입니다. 백업이 거의 항상 I / O 바운드이기 때문에 이것은 놀라운 일이 아닙니다. 데이터를 압축하면 I / O로드가 CPU로드와 교환되며 대부분의 CPU는 몬스터 데이터 전송 중에 유휴 상태이므로 압축이 순이익으로 나옵니다.

따라서 백업 / 복원 시간을 단축하려면 더 빠른 I / O가 필요합니다. 하나의 거대한 단일 인스턴스가되지 않도록 데이터베이스를 재구성하는 것 외에도 할 수있는 일은 거의 없습니다.