Як я можу запросити флеш журналів транзакцій postgresql?

У мене є така проблема: "вертикальний" дистрибутив 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, ніж нова.

З цікавості я запустив перевірку на версію та параметри pgsql за замовчуванням 7, і я отримав зовсім інші результати:

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
• depesz на WAL