我如何请求刷新Postgresql事务日志？

我遇到以下问题：PostgreSQL 9.2附带了一个“垂直” Linux发行版（Sophos UMT），用于存储其配置。不幸的是，自上次更新以来，某些实例的事务日志（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使用的空间要少得多。

出于好奇，我运行了版本和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然后停止并重新启动DB 可能会导致它开始主动写出排队的WAL。在执行检查点之前，它不会释放任何内容，但是一旦写入活动变慢（以sar，iostat等衡量），您就可以强制执行任何操作。我还没有进行测试，以查看checkpoint_completion_target在重新启动后进行更改时是否会影响已经编写的WAL；请考虑initdb首先在另一台计算机上对您进行一次性测试PostgreSQL上进行测试。

备份与WAL的保留和增长无关。它与备份无关。

看到：

• WAL的PostgreSQL手册
• 有关WAL配置的PostgreSQL手册
• Depesz on checkpoint_completion_target
• 沃尔斯·德佩斯