Как я могу запросить очистку журналов транзакций postgresql?

У меня следующая проблема: «Вертикальный» дистрибутив Linux (Sophos UMT) поставляется с PostgreSQL 9.2 для хранения его конфигурации. К сожалению, со времени последнего обновления создается впечатление, что журналы транзакций (WAL) некоторых экземпляров растут без каких-либо сбросов. Это приводит к тому, что папка pg_xlog растет на несколько порядков больше, чем базовая папка.

Сейчас я нахожусь в деликатной ситуации: из-за чрезмерного роста файлов WAL диск одной из этих машин (ВМ) будет заполнен до понедельника. Я уже открыл службу поддержки у поставщика, но пока они не очень полезны (они предлагают перестроить виртуальную машину с большими дисками).

Резервное копирование этой базы данных никогда не происходит, потому что программное обеспечение выполняет резервное копирование другим способом (оно имеет свою собственную процедуру резервного копирования и отправляет файлы резервных копий по электронной почте), и я полагаю, что именно по этой причине 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)

Edit2

Наконец, мы переустановили весь сервер (в соответствии с запросом поддержки Sophos), но с использованием предыдущей версии и диска большего размера. По-видимому, более старая версия использует гораздо меньше места для WAL, чем новая.

Из любопытства я запустил проверку параметров версии и 7non-default 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)

Мне кажется, что между этими двумя версиями произошло довольно много изменений.

Скорее всего, то, что вы видите, имеет огромное 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 = 1затем остановка и перезапуск БД могут привести к тому, что он начнет агрессивно записывать в очередь WAL. Он не освободит ничего, пока не выполнит контрольную точку, но вы можете заставить один раз замедлить запись (как измерено с помощью sar, iostat и т. Д.). Я не проверял, checkpoint_completion_targetвлияет ли уже написанное WAL при изменении при перезапуске; попробуйте проверить это на одноразовом тесте PostgreSQL initdbсначала на другой машине.

Резервные копии не имеют ничего общего с сохранением и ростом WAL; это не связано с резервным копированием.

Видеть:

• Руководство PostgreSQL по WAL
• Руководство PostgreSQL по настройке WAL
• депеш на checkpoint_completion_target
• Депес на WAL