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

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

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

Эта база данных никогда не копируется, потому что программное обеспечение выполняет резервное копирование по-другому (у него есть своя процедура резервного копирования и отправка файлов резервных копий по электронной почте), и я полагаю, что именно по этой причине WAF растут так сильно.

Я боюсь, что я далек от того, чтобы быть экспертом PostgreSQL, поэтому очень вероятно, что я задаю глупый или очевидный вопрос, но какова процедура запроса на сброс файлов WAL?

В идеале, я ищу процедуру, которая позволит мне очистить эти файлы WAL от проблемной системы, чтобы купить себе достаточно времени, чтобы заставить поставщика выпустить лучшее исправление.

Edit : В соответствии с запросом, вот результат запроса 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)

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

11 голосов | спросил Stephane 24 Maypm13 2013, 19:51:55

1 ответ


8

Скорее всего, вы видите огромное значение checkpoint_segments и long 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, ---- +: = 10 =: + ---- и т. д.). Не делайте этого во время работы сервера и не опускайте никаких файлов или папок, они важны all (ну, кроме base, но рекомендуется сохранять текстовые журналы в любом случае).

Если вы хотите получить более конкретный комментарий относительно вероятной причины (и поэтому я могу быть более уверенным в своей гипотезе), вы можете запускать следующие запросы и вставлять их вывод в свой ответ (в блоке с отступом с кодом), тогда комментарий, поэтому я уведомлен:

pg_log

Возможно, что установка SELECT version(); SELECT name, current_setting(name), source FROM pg_settings WHERE source NOT IN ('default', 'override'); , затем остановка и перезапуск DB может заставить его начать агрессивно писать вне очереди WAL. Он не освободит его до тех пор, пока он не выполнит контрольную точку, но вы можете заставить один раз, когда активность записи замедляется (как измеряется с помощью sar, iostat и т. Д.). Я не проверял, влияет ли checkpoint_completion_target = 1 на уже написанный WAL при изменении при перезагрузке; рассмотрите возможность тестирования этого на тестовом сценарии PostgreSQL, который вы checkpoint_completion_target на другой машине.

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

См:

ответил Craig Ringer 25 Mayam13 2013, 07:42:23

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132