Postgres에서 제로 WAL 세그먼트


9

각 WAL 세그먼트를 압축하고이를 S3로 전송하도록 연속 아카이브가 설정된 상대적으로 적은 양의 Postgres 데이터베이스가 있습니다. 이 시스템은 볼륨이 적기 때문에 archive_timeout10 분마다 적중하며 대부분 사용하지 않은 WAL 세그먼트를 보관합니다.이 세그먼트 압축률이 높았지만 대부분 0에 불과했습니다.

그러나 Postgres는 각 WAL 스위치에서 새 파일을 할당하는 비용을 피하기 위해 WAL 세그먼트를 재활용합니다. 이는 높은로드 상황에서 유용하지만 정상보다 무거운 활동이 급증한 후 WAL 세그먼트 파일이 가득 찼음을 의미합니다. 이전 세그먼트의 정크 및 전혀 압축하지 않습니다. 우리는이 쓰레기의 많은 사본을 저장하고 있습니다.

WAL 아카이브를 유지하기 위해 사용중인 공간을 줄일 수있는 방법이 있습니까? 차선책 가능성 :

  1. Postgres가 어떻게 든 WAL 세그먼트를 재활용하지 못하도록 매번 파일을 0으로 시작합니다. 문서에는이 작업을 수행 할 수있는 옵션이 표시되어 있지 않지만 누락되었을 수 있습니다.

  2. Postgres가 WAL 세그먼트 파일을 사용하여 시작 / 종료 할 때 0으로 설정하십시오. 다시 말하지만, 문서는 이것이 가능하다고 제안하지 않는 것 같습니다.

  3. 사용하지 않는 WAL 세그먼트 파일 중 일부를 외부에서 제로화하거나 제거하십시오. 이것이 어떤 파일인지 결정하는 안전한 방법이 있습니까?

  4. pg_xlogdump정크 출력이 시작된 위치를 찾기 위해 출력을 사용하여 보관하기 전에 세그먼트의 사용되지 않은 부분을 0으로 만듭니다. 비록 그것을 좋아하지는 않지만 가능합니다. 적어도 archive 명령에서 이것을 수행하면 Postgres가 파일을 재사용하지 않을 것입니다.

  5. pg_xlogdump어떻게 든 출력을 해석하여 세그먼트 파일의 사용 된 부분 만 다시 아카이브 한 다음 복원 중에 0으로 채 웁니다. 정말 멋진 것은 아니지만 가능합니다.


재미있는 문제. 어떤 연속 보관을 사용하고 있는지 물어볼 수 있습니까?
dezso

@dezso 이탈이 적음에도 불구하고 가능한 한이 데이터를 잃을 위험을 줄이고 변경 사항을 감사 추적하는 것이 매우 중요합니다. WAL 아카이빙은 최후의 방어선 (다른 메커니즘도 사용 중)이므로 저렴하게 유지하는 것이 좋습니다.
Dave Turner

답변:


5

버전 9.4부터는 WAL 파일의 꼬리 끝을 자동으로 0으로 만듭니다. (실제로 거의 0입니다. 제로되지 않는 블록 헤더가 있지만 결과는 매우 압축 가능합니다).

버전 9.2에는 pg_clearxlogtail사용할 수 있는 프로그램 이 있습니다. 압축 단계 전에 archive_command에 추가 할 수 있습니다.

9.3을 사용하는 경우 운이 좋지 않습니다.

체크 포인트는 본질적으로 로그 파일 전환을 유발하지 않습니다. 아마도 archive_timeout이 원인 일 수 있습니다.


도 예, 우리는 9.3에 있으므로 두 솔루션 사이의 균열을 극복했습니다. 그리고 네, 죄송 archive_timeout합니다. 스위치의 원인 이 맞습니다 . OP를 수정했습니다. 감사합니다.
Dave Turner
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.