postgresql 트랜잭션 로그 플러시를 요청하려면 어떻게해야합니까?


11

다음과 같은 문제가 있습니다. "수직"Linux 배포 (Sophos UMT)는 PostgreSQL 9.2와 함께 구성을 저장합니다. 불행히도 마지막 업데이트 이후 일부 인스턴스의 트랜잭션 로그 (WAL)가 플러시되지 않고 커지고있는 것 같습니다. 이로 인해 pg_xlog 폴더가 기본 폴더보다 몇 배 더 커집니다.

WAL 파일의 과도한 증가로 인해이 머신 중 하나 (VM)의 디스크가 월요일 전에 가득 찰 것입니다. 이미 공급 업체와 지원 사례를 열었지만 지금까지는 큰 도움이되지 않습니다 (더 큰 디스크로 VM을 다시 작성하는 것이 좋습니다).

이 데이터베이스는 소프트웨어가 다른 방식으로 백업을 수행하기 때문에 자체 백업 절차가 있고 이메일로 백업 파일을 전송하기 때문에 백업되지 않으며 WAF가 너무 커지는 이유라고 생각합니다.

PostgreSQL 전문가가 아니기 때문에 어리 석거나 명백한 질문을 할 가능성이 높지만 WAL 파일을 플러시하도록 요청하는 절차는 무엇입니까?

이상적으로는 벤더가 더 나은 수정 프로그램을 발행 할 수 있도록 충분한 시간을 확보하기 위해 문제가있는 시스템에서 이러한 WAL 파일을 플러시 할 수있는 절차를 찾고 있습니다.

편집 : 요청한대로 다음은 SELECT version();쿼리 출력입니다 .

 PostgreSQL 9.2.4 on i686-pc-linux-gnu, compiled by gcc (SUSE Linux) 4.3.4 [gcc-4_3-branch revision 152973], 32-bit

(1 행)

그리고 SELECT name, current_setting(name), source FROM pg_settings WHERE source NOT IN ('default', 'override');쿼리

 hot_standby                      | on                  | configuration file
 listen_addresses                 | *                   | configuration file
 log_destination                  | syslog              | configuration file
 log_min_duration_statement       | -1                  | configuration file
 log_min_error_statement          | error               | configuration file
 log_min_messages                 | notice              | configuration file
 maintenance_work_mem             | 512MB               | configuration file
 max_connections                  | 300                 | configuration file
 max_files_per_process            | 1000                | configuration file
 max_prepared_transactions        | 0                   | configuration file
 max_stack_depth                  | 2MB                 | configuration file
 max_standby_streaming_delay      | 10s                 | configuration file
 max_wal_senders                  | 10                  | configuration file
 password_encryption              | on                  | configuration file
 pg_stat_statements.max           | 1000                | configuration file
 pg_stat_statements.save          | on                  | configuration file
 pg_stat_statements.track         | all                 | configuration file
 pg_stat_statements.track_utility | off                 | configuration file
 port                             | 5432                | configuration file
 random_page_cost                 | 2                   | configuration file
 replication_timeout              | 1min                | configuration file
 seq_page_cost                    | 1                   | configuration file
 shared_buffers                   | 512MB               | configuration file
 shared_preload_libraries         | pg_stat_statements  | configuration file
 ssl                              | off                 | configuration file
 stats_temp_directory             | pg_stat_tmp         | configuration file
 superuser_reserved_connections   | 20                  | configuration file
 synchronous_commit               | local               | configuration file
 syslog_facility                  | local0              | configuration file
 syslog_ident                     | postgres            | configuration file
 temp_buffers                     | 256MB               | configuration file
 temp_file_limit                  | -1                  | configuration file
 TimeZone                         | GMT                 | configuration file
 timezone_abbreviations           | AlmostAll           | configuration file
 track_activities                 | on                  | configuration file
 track_activity_query_size        | 4096                | configuration file
 track_counts                     | on                  | configuration file
 track_functions                  | none                | configuration file
 track_io_timing                  | on                  | configuration file
 unix_socket_directory            | /var/run/postgresql | configuration file
 unix_socket_group                | postgres            | configuration file
 unix_socket_permissions          | 0777                | configuration file
 update_process_title             | on                  | configuration file
 vacuum_defer_cleanup_age         | 0                   | configuration file
 wal_buffers                      | 16MB                | configuration file
 wal_keep_segments                | 100                 | configuration file
 wal_level                        | hot_standby         | configuration file
 wal_receiver_status_interval     | 5s                  | configuration file
 work_mem                         | 512MB               | configuration file
(69 rows)

편집 2

마지막으로 Sophos 지원팀의 요청에 따라 전체 서버를 다시 설치했지만 이전 버전과 더 큰 디스크를 사용했습니다. 분명히 이전 버전은 새 버전보다 WAL에 훨씬 적은 공간을 사용하고 있습니다.

호기심으로 인해 버전 및 7 기본이 아닌 pgsql 매개 변수에 대한 검사를 실행했으며 결과가 다릅니다.

PostgreSQL 8.4.14 on i686-pc-linux-gnu, compiled by GCC gcc (SUSE Linux) 4.3.4 [gcc-4_3-branch revision 152973], 32-bit

              name               | current_setting |        source
---------------------------------+-----------------+----------------------
 autovacuum_analyze_scale_factor | 0.0005          | configuration file
 checkpoint_segments             | 12              | configuration file
 checkpoint_warning              | 0               | configuration file
 escape_string_warning           | off             | configuration file
 fsync                           | on              | configuration file
 listen_addresses                | *               | configuration file
 log_destination                 | syslog          | configuration file
 log_timezone                    | Europe/Zurich   | command line
 maintenance_work_mem            | 1GB             | configuration file
 max_connections                 | 300             | configuration file
 max_stack_depth                 | 2MB             | environment variable
 port                            | 5432            | configuration file
 shared_buffers                  | 32MB            | configuration file
 standard_conforming_strings     | off             | configuration file
 syslog_facility                 | local0          | configuration file
 syslog_ident                    | postgres        | configuration file
 temp_buffers                    | 1024            | configuration file
 TimeZone                        | UTC             | configuration file
 timezone_abbreviations          | AlmostAll       | configuration file
 work_mem                        | 512MB           | configuration file
(20 rows)

이 두 버전 사이에 많은 변화가 있었던 것처럼 보입니다.

답변:


9

아마도 당신이보고있는 것은 큰 checkpoint_segments가치와 긴 것입니다 checkpoint_timeout. 또는 wal_keep_segments스트리밍 복제를 지원해야하는 경우 매우 큰 값으로 설정되었을 수 있습니다 .

CHECKPOINT명령 으로 체크 포인트를 강제 실행할 수 있습니다 . 데이터베이스에 대량의 WAL이 축적되어 있고 백그라운드로 작성되지 않은 경우 데이터베이스가 잠시 정지 될 수 있습니다. 경우 checkpoint_completion_target(0.8 미만 또는 0.9) 낮은 다음 될 가능성이있어 체크 포인트 시간에 할 일이 백 로그. 체크 포인트 동안 데이터베이스가 느리고 응답하지 않도록 준비하십시오. 검사 점이 정상적인 방법으로 시작되면 중단 할 수 없습니다. 데이터베이스를 크래시하고 다시 시작할 수는 있지만 원래 위치로 돌아갑니다.

확실하지는 않지만 체크 포인트가 기본 데이터베이스가 커질 수 있다고 생각합니다. WAL에 공간이 확보되기 전에 여유 공간을 확보하기 전에 그렇게하십시오. 따라서 체크 포인트로 인해 공간이 부족해질 수 있습니다. 최소한 일시적으로 스토리지를 추가하지 않으면 복구하기가 매우 어렵습니다.

이제 데이터베이스의 적절한 백업을 얻는 데 아주 좋은 시간입니다. pg_dump -Fc dbname각 데이터베이스 pg_dumpall --globals-only를 덤프하고 사용자 정의를 덤프하는 데 사용하십시오.

당신이 다운 타임을 줄 수있는 경우, 데이터베이스를 중지하고 전체 데이터 디렉토리의 파일 시스템 레벨 사본 (포함 된 폴더 가지고 pg_xlog, pg_clog, global, base, 등). 서버가 실행 중일 때이 작업을 수행하지 말고 파일이나 폴더를 생략하지 마십시오. 파일이나 폴더는 모두 중요합니다 (단 pg_log,를 제외하고 는 텍스트 로그를 유지하는 것이 좋습니다).

가능한 원인에 대한보다 구체적인 의견을 원한다면 (그리고 가설이 더 확신 할 수 있습니다) 다음 쿼리를 실행하고 결과를 코드 들여 쓰기 블록으로 답변에 붙여 넣을 수 있습니다. '알림 :

SELECT version();

SELECT name, current_setting(name), source
  FROM pg_settings
  WHERE source NOT IN ('default', 'override');

checkpoint_completion_target = 1DB 를 설정 한 다음 중지했다가 다시 시작하면 대기중인 WAL을 적극적으로 작성하기 시작할 있습니다. 체크 포인트를 수행 할 때까지 아무것도 해제하지 않지만 sar, iostat 등으로 측정 한 쓰기 작업 속도가 느려지면 강제로 할 수 있습니다. checkpoint_completion_target다시 시작할 때 변경 될 때 이미 작성된 WAL에 영향을 주는지 테스트하지 않았습니다 . initdb먼저 다른 시스템에서 PostgreSQL 테스트를 수행하는 것이 좋습니다 .

백업은 WAL 보존 및 성장과 아무 관련이 없습니다. 백업 관련이 없습니다.

보다:


자세한 답변을 주셔서 감사합니다. 귀하가 제공 한 두 개의 쿼리 결과를 질문에 따라 업데이트했습니다. 그래도 체크 포인트와 관련된 것을 볼 수 없습니다. 그 동안 우리는 총알을 물고 전체 시스템을 더 큰 디스크로 다시 설치하기로 결정했습니다. 그러면 Sophos에서 지원되는 수정 프로그램을 얻을 수있는 충분한 시간이 제공됩니다.
Stephane

@Stephane 다시 설치할 필요가 없습니다 . 기존 머신을 더 큰 디스크로 디스크 이미지를 생성 한 다음 PostgreSQL을 새로 생성 된 더 큰 파티션으로 옮길 수 있습니다. 즉, 저수준 Linux sysadmin 경험에 따라 다시 설치하기가 더 쉬울 수 있습니다.
Craig Ringer 12

@Stephane Your (으 wal_keep_segments)로 설정되어 100있으므로 마스터 서버에서 더 이상 필요하지 않은 스트리밍 복제본에서 사용할 수 있도록 최대 1.6GB의 WAL 아카이브를 보유해야합니다. 마스터 서버로 스트리밍 복제를 사용하지 않는 경우 wal_keep_segments0으로 설정 하고 해당 공간을 다시 확보 할 수 있습니다 . 귀하 checkpoint_segments가 기본값 인 것처럼 보이므로 귀하가 아닌 경우 WAL이 3 * 16 = 48MB를 넘지 않아야합니다 wal_keep_segments. 전원을 hot_standby켠 것도 이상합니다 . 복제본입니까?
Craig Ringer 12

다시 감사합니다. 시스템은 복제본의 일부가 아니지만이를 사용하는 소프트웨어 (Sopho UTM 방화벽)를 액티브 / 패시브 페일 오버 모드에서 사용할 수 있으므로 기본적으로 설정되어있을 수 있습니다.
스테판

@ 스테판 그래, 그거야. 내가 돌려 줄 wal_keep_segments0개인적으로 PostgreSQL을 다시 시작합니다. 원하지 않는 WAL을 제거한다는 것을 확인하지는 않았지만 그렇게 할 것으로 기대합니다. 수동으로 제거하지 않는 것이 좋습니다. 잘못된 WAL 보관 파일을 제거하면 데이터베이스 작동이 완전히 중지됩니다.
Craig Ringer
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.