Jak mogę poprosić o opróżnienie dzienników transakcji postgresql?

Mam następujący problem: „pionowa” dystrybucja Linuksa (Sophos UMT) jest dostarczana z PostgreSQL 9.2 do przechowywania konfiguracji. Niestety od czasu ostatniej aktualizacji wydaje się, że dzienniki transakcji (WAL) niektórych instancji rosną bez opróżniania. Powoduje to, że folder pg_xlog rośnie o kilka rzędów wielkości większy niż folder podstawowy.

Jestem teraz w delikatnej sytuacji: z powodu nadmiernego wzrostu plików WAL dysk jednego z tych komputerów (VM) zapełni się przed poniedziałkiem. Już otworzyłem skrzynkę pomocy technicznej u dostawcy, ale jak dotąd nie są bardzo pomocni (sugerują, że przebudujemy maszynę wirtualną z większymi dyskami).

Ta baza danych nigdy nie jest tworzona, ponieważ oprogramowanie wykonuje kopie zapasowe w inny sposób (ma własną procedurę tworzenia kopii zapasowych i wysyła pliki kopii zapasowych pocztą e-mail) i przypuszczam, że to jest powód, dla którego WAF tak bardzo się rozwijają.

Obawiam się, że daleko mi do bycia ekspertem PostgreSQL, więc prawdopodobnie zadaję głupie lub oczywiste pytanie, ale jaka jest procedura żądania usunięcia plików WAL?

Idealnie szukam procedury, która pozwoli mi opróżnić te pliki WAL w problematycznym systemie, aby kupić sobie wystarczająco dużo czasu, aby zmusić sprzedawcę do wydania lepszej poprawki.

Edycja : zgodnie z żądaniem, oto wynik SELECT version();zapytania:

 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 rząd)

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

 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)

Edytuj2

W końcu ponownie zainstalowaliśmy cały serwer (zgodnie z żądaniem wsparcia Sophos), ale używając poprzedniej wersji i większego dysku. Najwyraźniej starsza wersja zajmuje dużo mniej miejsca na WAL niż nowa.

Z ciekawości uruchomiłem sprawdzanie wersji i 7-domyślnych parametrów pgsql i otrzymałem zupełnie inne wyniki:

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

i

              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)

Wydaje mi się, że pomiędzy tymi dwoma wersjami było sporo zmian.

Najprawdopodobniej to, co widzisz, ma ogromną checkpoint_segmentswartość i jest długie checkpoint_timeout; naprzemiennie mogliby ustawić wal_keep_segmentsbardzo dużą wartość, jeśli ma ona obsługiwać replikację strumieniową.

Możesz wymusić punkt kontrolny za pomocą CHECKPOINTpolecenia. Może to zablokować bazę danych na jakiś czas, jeśli zgromadził ogromną ilość WAL i nie pisał jej w tle. Jeśli checkpoint_completion_targetjest niski (mniej niż 0,8 lub 0,9), prawdopodobnie w punkcie kontrolnym będzie dużo pracy do wykonania. Przygotuj się na spowolnienie bazy danych i brak reakcji w punkcie kontrolnym. Nie można przerwać punktu kontrolnego, gdy zaczyna się on zwykłymi środkami; możesz zawiesić bazę danych i zrestartować ją, ale to po prostu przywraca Cię do poprzedniego stanu.

Nie jestem pewien, ale mam wrażenie, że punkt kontrolny może również spowodować wzrost głównej bazy danych - i zrobić to, zanim jakaś przestrzeń zostanie zwolniona w WAL, jeśli w ogóle jest. Punkt kontrolny może potencjalnie spowodować brak miejsca, co jest bardzo trudne do odzyskania bez dodawania dodatkowego miejsca, przynajmniej tymczasowo.

Byłby to bardzo dobry moment na uzyskanie właściwej kopii zapasowej bazy danych - użyj jej pg_dump -Fc dbnamedo zrzucenia każdej bazy danych i pg_dumpall --globals-onlydo zrzucenia definicji użytkowników itp.

Jeśli możesz sobie pozwolić na przestoje, stop bazy danych i zrobić kopię systemu plików na poziomie całego katalogu danych (folder zawierający pg_xlog, pg_clog, global, base, etc). Nie rób tego, gdy serwer jest uruchomiony i nie pomijaj żadnych plików ani folderów, wszystkie są ważne (no cóż, z wyjątkiem pg_log, ale i tak warto przechowywać dzienniki tekstowe).

Jeśli potrzebujesz bardziej szczegółowego komentarza na temat prawdopodobnej przyczyny (i mogę być bardziej pewny mojej hipotezy), możesz uruchomić następujące zapytania i wkleić ich dane wyjściowe do swojej odpowiedzi (w bloku z wcięciem kodu), a następnie skomentować, więc I otrzymałem powiadomienie:

SELECT version();

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

Możliwe, że ustawienie, checkpoint_completion_target = 1a następnie zatrzymanie i zrestartowanie bazy danych może spowodować, że zacznie ona agresywnie zapisywać kolejkę WAL w kolejce. Nie zwolni żadnego, dopóki nie wykona punktu kontrolnego, ale możesz wymusić jedno, gdy aktywność zapisu zostanie spowolniona (mierzone sar, iostat itp.). Nie testowałem, aby sprawdzić, czy checkpoint_completion_targetwpływa na już napisany WAL po zmianie w ponownym uruchomieniu; rozważ przetestowanie tego najpierw initdbna testowym serwerze PostgreSQL na innym komputerze.

Kopie zapasowe nie mają nic wspólnego z utrzymywaniem i rozwojem WAL; nie jest związane z tworzeniem kopii zapasowych.

Widzieć:

• Podręcznik PostgreSQL na WAL
• Podręcznik PostgreSQL dotyczący konfiguracji WAL
• depesz on checkpoint_completion_target
• depesz na WAL