Azure Database for PostgreSQL - 유연한 서버의 pg_dump 및 pg_restore에 대한 모범 사례
적용 대상: 
Azure Database for PostgreSQL - 유연한 서버
이 문서에서는 pg_dump 및 pg_restore를 가속화하기 위한 옵션 및 모범 사례를 검토합니다. 또한 pg_restore를 수행하기 위한 최상의 서버 구성에 대해서도 설명합니다.
pg_dump에 대한 모범 사례
pg_dump 유틸리티를 사용하여 Azure Database for PostgreSQL 유연한 서버 데이터베이스를 스크립트 파일 또는 보관 파일로 추출할 수 있습니다. pg_dump를 사용하여 전체 덤프 시간을 줄이는 데 사용할 수 있는 몇 가지 명령줄 옵션이 다음 섹션에 나열되어 있습니다.
디렉터리 형식(-Fd)
이 옵션은 pg_restore에 입력할 수 있는 디렉터리 형식 보관 파일을 출력합니다. 기본적으로 출력은 압축됩니다.
병렬 작업(-j)
pg_dump를 사용하면 병렬 작업 옵션을 사용하여 덤프 작업을 동시에 실행할 수 있습니다. 이 옵션을 사용하면 총 덤프 시간은 줄어들지만 데이터베이스 서버의 로드는 늘어납니다. CPU, 메모리 및 IOPS(초당 입력/출력 작업) 사용량과 같은 원본 서버 메트릭을 면밀히 모니터링한 후 병렬 작업 값에 도달하는 것이 좋습니다.
병렬 작업 옵션에 대한 값을 설정하는 경우 pg_dump에는 다음이 필요합니다.
- 연결 수는 병렬 작업 수 +1과 같아야 하므로 그에 따라
max_connections값을 설정해야 합니다. - 병렬 작업 수는 데이터베이스 서버에 할당된 vCPU 수보다 작거나 같아야 합니다.
압축(-Z0)
이 옵션은 사용할 압축 수준을 지정합니다. 0은 압축이 없음을 의미합니다. pg_dump 프로세스 중에 압축이 0이면 성능 향상에 도움이 될 수 있습니다.
테이블 블로트 및 진공
pg_dump 프로세스를 시작하기 전에 테이블 진공이 필요한지 여부를 고려합니다. 테이블의 블로트는 pg_dump 시간을 크기 증가시킵니다. 다음 쿼리를 실행하여 테이블 블로트를 식별합니다.
select schemaname,relname,n_dead_tup,n_live_tup,round(n_dead_tup::float/n_live_tup::float*100) dead_pct,autovacuum_count,last_vacuum,last_autovacuum,last_autoanalyze,last_analyze from pg_stat_all_tables where n_live_tup >0;
이 쿼리의 dead_pct 열은 라이브 튜플과 비교할 때 데드 튜플의 백분율입니다. 테이블의 dead_pct 값이 높으면 테이블이 제대로 진공 처리되지 않은 것일 수 있습니다. 자세한 내용은 Azure Database for PostgreSQL - 유연한 서버의 자동 진공 튜닝을 참조하세요.
식별하는 각 테이블에 대해 다음을 실행하여 수동 진공 분석을 수행할 수 있습니다.
vacuum(analyze, verbose) <table_name>
PITR 서버 사용
온라인 또는 라이브 서버에서 pg_dump를 수행할 수 있습니다. 데이터베이스를 사용하는 경우에도 일관된 백업이 생성됩니다. 다른 사용자가 데이터베이스를 사용하지 못하도록 차단하지는 않습니다. pg_dump 프로세스를 시작하기 전에 데이터베이스 크기와 기타 비즈니스 또는 고객 요구 사항을 고려합니다. 소규모 데이터베이스는 프로덕션 서버에서 pg_dump를 수행하기에 적합한 후보일 수 있습니다.
대규모 데이터베이스의 경우 프로덕션 서버에서 PITR(특정 시점 복구) 서버를 만들고 PITR 서버에서 pg_dump 프로세스를 수행할 수 있습니다. PITR에서 pg_dump를 실행하는 것은 콜드 실행 프로세스입니다. 이 방법의 단점은 실제 프로덕션 서버에서 실행되는 pg_dump 프로세스와 함께 제공되는 추가 CPU, 메모리 및 IO 사용률과 관련이 없다는 것입니다. PITR 서버에서 pg_dump를 실행한 다음, pg_dump 프로세스가 완료된 후 PITR 서버를 삭제할 수 있습니다.
pg_dump 구문
pg_dump에 다음 구문을 사용합니다.
pg_dump -h <hostname> -U <username> -d <databasename> -Fd -j <Num of parallel jobs> -Z0 -f sampledb_dir_format
pg_restore에 대한 모범 사례
pg_restore 유틸리티를 사용하여 pg_dump로 만든 보관 파일에서 Azure Database for PostgreSQL 유연한 서버 데이터베이스를 복원할 수 있습니다. 전체 복원 시간을 줄이기 위한 몇 가지 명령줄 옵션이 다음 섹션에 나열되어 있습니다.
병렬 복원
여러 동시 작업을 사용하면 다중 vCore 대상 서버에서 큰 데이터베이스를 복원하는 데 걸리는 시간을 줄일 수 있습니다. 작업 수는 대상 서버에 할당된 vCPU 수와 같거나 작을 수 있습니다.
서버 매개 변수
새 서버 또는 비프로덕션 서버로 데이터를 복원하는 경우 pg_restore를 실행하기 전에 다음 서버 매개 변수를 최적화할 수 있습니다.
work_mem = 32MB
max_wal_size = 65536(64GB)
checkpoint_timeout = 3600 #60min
maintenance_work_mem = 2097151(2GB)
autovacuum = off
wal_compression = on
복원이 완료되면 이러한 모든 매개 변수가 워크로드 요구 사항에 따라 적절하게 업데이트되었는지 확인합니다.
참고 항목
메모리 및 디스크 공간이 충분한 경우에만 위의 권장 사항을 따릅니다. vCore가 2개, 4개 또는 8개인 작은 서버가 있는 경우 그에 따라 매개 변수를 설정합니다.
기타 고려 사항
- pg_restore를 실행하기 전에 HA(고가용성)를 사용하지 않도록 설정합니다.
- 복원이 완료된 후 마이그레이션되는 모든 테이블을 분석합니다.
pg_restore 구문
pg_restore에 다음 구문을 사용합니다.
pg_restore -h <hostname> -U <username> -d <db name> -Fd -j <NUM> -C <dump directory>
-Fd: 디렉터리 형식입니다.-j: 작업의 수입니다.-C: 명령으로 출력을 시작하여 데이터베이스 자체를 만든 다음, 다시 연결합니다.
다음은 이 구문이 표시되는 방법의 예입니다.
pg_restore -h <hostname> -U <username> -j <Num of parallel jobs> -Fd -C -d <databasename> sampledb_dir_format
가상 머신 고려 사항
대상 서버와 원본 서버가 모두 있는 동일한 지역 및 가용성 영역에 가상 머신을 만듭니다. 또는 최소한 가상 머신을 원본 서버 또는 대상 서버에 더 가깝게 만듭니다. 고성능 로컬 SSD에서 Azure Virtual Machines를 사용하는 것이 좋습니다.
SKU에 대한 자세한 내용은 다음을 참조하세요.