如何请求刷新 postgresql 事务日志？

Question

我有以下问题：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 使用的空间比新版本少得多。

出于好奇，我检查了 version 和 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)

在我看来，这两个版本之间有很多变化。

Answer 1

很可能你看到的是一个巨大的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；考虑initdb先在另一台机器上的一次性测试 PostgreSQL 上进行测试。

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

看：

• WAL 上的 PostgreSQL 手册
• 关于 WAL 配置的 PostgreSQL 手册
• 下沉 checkpoint_completion_target
• WAL 上的 depesz