pg_dump를 덜 탐욕스럽게 만드는 방법

다음 규칙을 사용하여 매일 pg_dump를 호출하도록 cron을 구성했습니다.

# xyz database backups:
00 01 * * * root umask 077 && pg_dump --user=xyz_system xyz | gzip > /var/xyz/backup/db/xyz/`date -u +\%Y\%m\%dT\%H\%M\%S`.gz

기본적으로 작동합니다. 데이터베이스는 상대적으로 빠르게 기하 급수적으로 증가하지만 지수는 그리 크지 않습니다. 현재 gzipped 덤프는 약 160MB를 사용합니다. 데이터베이스가 덤프되면 시스템 크롤링이 시작됩니다. top명령을 사용하여 본로드 평균 은 약 200, 200, 180입니다. 기본적으로 서버는 응답이 거의 없습니다.

첫 번째 질문 은 병목 현상의 위치를 ​​확인하는 방법입니다. 과도한 I / O 작업으로 인해 성능이 저하됩니까? 테이블 잠금 문제로 인해 발생합니까? 메모리 문제일까요? pg_dump명령 의 출력이 명령으로 파이프됩니다 gzip. 순차적입니까, 즉 전체 덤프가 메모리에 배치 된 후 (스왑 문제입니까?) 압축 또는 동시입니까 (예 : gzip이 가져오고 기다리는 것을 압축)? 다른 요인으로 인해 발생할 수 있습니까?

두 번째 질문 은 시스템의 주요 기능에 대해 덤프 작업을 덜 방해하는 방법입니다. 내가 이해하는 한 데이터베이스 무결성으로 인해 덤프 시간이 너무 오래 걸리지 않습니다. 테이블 쓰기 잠금 등이 있습니다. 문제점을 제한하기 위해 수행 할 수있는 작업 (또는 데이터베이스 증가를 고려하여 지연)

세 번째 질문은 : 이미 고급 데이터베이스 구성에 대해 배울 수있는 시간인가? 데이터베이스 백업이 수행되지 않을 때 시스템이 정상적으로 작동하지만 DB 덤프 문제가 들어오는 문제의 첫 증상일까요?

와. 놀라운 질문입니다. 일부 문제를 해결하려고 노력하지만이 답변은 아직 완료되지 않았습니다.

병목 현상의 위치를 ​​확인하는 방법

top덤프 중에 무슨 일이 일어나고 있는지 보려면 먼저 사용하십시오 . 프로세스 CPU 사용량, 프로세스 상태를 검사하십시오. D"I / O 대기 중"을 의미합니다.

과도한 I / O 작업으로 인해 성능이 저하됩니까?

그렇습니다.

테이블 잠금 문제로 인해 발생합니까?

아마도. pg_stat_activity시스템 뷰를 사용 하여 덤프 도중 postgres에서 진행중인 작업을 확인할 수 있습니다 .

메모리 문제일까요?

거의 없을 것입니다.

pg_dump 명령의 출력은 gzip 명령으로 파이프됩니다. 순차적입니까, 즉 전체 덤프가 메모리에 배치됩니다 (스와핑 문제?)

아니요. gzip은 스트림 모드에서 작동하는 블록 압축기이며 모든 입력을 메모리에 유지하지는 않습니다.

그런 다음 압축 또는 동시 (예 : gzip은 가져 오는 것을 압축하고 더 기다립니다)?

예, 블록별로 압축하고 출력하며 더 기다립니다.

다른 요인으로 인해 발생할 수 있습니까?

예.

내가 이해하는 한 데이터베이스 무결성으로 인해 덤프 시간이 너무 오래 걸리지 않습니다. 테이블 쓰기 잠금 등이 있습니다. 문제점을 제한하기 위해 수행 할 수있는 작업 (또는 데이터베이스 증가를 고려하여 지연)

덤프 지속 시간은 덤프 무결성에 영향을 미치지 않습니다. 모든 pg_dump 프로세스에 의해 반복 가능한 읽기 격리 수준으로 하나의 트랜잭션을 사용하여 무결성을 보장 합니다. 테이블 쓰기 잠금이 없습니다.

이미 고급 데이터베이스 구성에 대해 배울 때입니까? 데이터베이스 백업이 수행되지 않을 때 시스템이 정상적으로 작동하지만 DB 덤프 문제가 들어오는 문제의 첫 증상일까요?

너무 늦지 않았습니다. http://wiki.postgresql.org/wiki/Performance_Optimization로 시작 하십시오 .

postgresql 을 지속적으로 보관 하는 것이 좋습니다 . pg_dump를 사용하는 것의 장점은 다음과 같습니다.

1. 매번 전체 백업을 수행 할 필요가 없습니다. 처음에는 하나의 전체 백업으로 충분하지만 예를 들어 며칠마다 전체 백업을 수행하는 것이 좋습니다.
2. DB 크기가 커지면 복원 속도가 훨씬 빠릅니다.
3. 다른 시점으로 복원하는 기능 (Point-In-Time Recovery).
4. 1 시간마다 (30 분 정도) 증분 백업을 수행합니다. 이것은 구성 할 수 있으며 업데이트 활동에 따라 다릅니다.

그러나 몇 가지 단점이 있습니다 (대부분의 경우 문제가되지 않을 수 있음).

1. 이진 백업이므로 일반적으로 더 많은 공간이 필요합니다. DB 폴더를 압축 할 수 있습니다.
2. 다른 아키텍처 (이진 데이터)에서는 복원 할 수 없습니다.