DevOps知识中心
DevOps知识中心

排查高 WAL 活动和管理归档日志磁盘空间

学习如何排查和管理 PostgreSQL 中过度的预写日志 (WAL) 生成。本指南涵盖了高 WAL 活动的常见原因，例如批量操作和复制问题，并提供了配置 WAL 归档、管理复制槽以及防止磁盘空间耗尽的实用解决方案。对于专注于稳定性和高效磁盘空间利用的 PostgreSQL 管理员来说，这是必读内容。

46 浏览量

WAL 活动高涨的故障排除与归档日志磁盘空间管理

PostgreSQL 中过高的预写式日志 (Write-Ahead Log, WAL) 活动是一个严重问题，可能导致磁盘空间迅速耗尽，甚至造成数据库停机。WAL 是 PostgreSQL 确保数据持久性和可恢复性的机制。对数据库所做的每一次更改都必须先写入 WAL，然后才能应用于数据文件。虽然 WAL 至关重要，但如果归档或清理流程配置不当，过度的 WAL 生成会迅速耗尽可用磁盘空间。

本文深入探讨了 WAL 生成量过高的常见原因，并提供了有效管理归档日志磁盘空间的实用策略。通过理解底层机制并实施适当的配置，您可以预防与磁盘相关的故障，并维护 PostgreSQL 环境的健康运行。

了解预写式日志 (WAL)

在进行故障排除之前，了解 WAL 的工作原理至关重要。PostgreSQL 使用 WAL 来确保事务具有原子性（Atomic）、一致性（Consistent）、隔离性（Isolated）和持久性（Durable）（即 ACID 特性）。当数据库发生更改时，描述该更改的记录会写入 WAL 缓冲区，然后刷新到磁盘上的 WAL 文件。这确保了即使服务器在数据页更新之前崩溃，也可以在恢复期间从 WAL 重新应用这些更改。

WAL 文件以段（segments）的形式进行管理，默认大小通常为 16MB。随着新事务的发生，新的 WAL 文件不断创建。这些文件会迅速积累，如果管理不当（例如，未及时归档和移除），它们将消耗所有可用的磁盘空间。

关键 WAL 概念：

  • 持久性： 确保一旦事务提交，它就能在系统故障中幸存下来。
  • 复制： WAL 是流复制的基础，备用服务器接收 WAL 记录以与主服务器保持同步。
  • 时间点恢复 (PITR)： WAL 归档对于 PITR 至关重要，它允许您将数据库恢复到任何特定的时间点。
  • WAL 段： WAL 数据被写入一系列称为“段”的文件中。

WAL 活动高涨的常见原因

有几个因素可能导致 WAL 生成量异常高。确定根本原因是有效故障排除的第一步。

1. 批量数据加载和修改

诸如 INSERT、UPDATE、DELETE、TRUNCATE 和 COPY 等操作会生成大量的 WAL。批量操作，尤其是在大表上，自然会比小的、单独的事务产生更多的 WAL 记录。

  • 示例： 单个用于插入数百万行的 COPY FROM 命令可以生成数 GB 的 WAL 数据。
  • 示例： 运行大规模数据迁移或批处理更新脚本。

2. 复制延迟和备用服务器问题

如果您的备用服务器未能跟上主服务器（即复制延迟），WAL 文件将在主服务器上累积。主服务器不能移除已完成的 WAL 段，除非确认它们已被发送给所有连接的备用服务器并已由其处理（如果 wal_keep_size 或 max_slot_wal_keep_size 未配置，或者槽使用不正确）。

  • 场景： 备用服务器停机、断开连接或遇到性能问题，使其无法从主服务器消费 WAL 记录。

3. 过多的 fsync 调用（不常见但可能）

虽然 WAL 本身是主要驱动因素，但低效的应用程序逻辑或某些 PostgreSQL 配置可能导致更频繁地刷新到磁盘，从而间接增加 WAL 活动。然而，这比批量操作或复制问题更不常见。

4. pg_wal 目录未受管理地增长

如果 WAL 归档未启用或失败，则主服务器上的 pg_wal（以前是 pg_xlog）目录将随着新 WAL 段的生成而无限期增长。

5. 复制槽未被回收

复制槽（Replication slots）保证 WAL 段不会在其被特定的备用服务器或逻辑解码客户端消费之前被移除。如果创建了一个槽，但消费者停止或断开连接而该槽未被删除，则该槽所需的 WAL 段将被保留，即使备用服务器不再活跃。

管理 WAL 磁盘空间：配置和解决方案

解决高 WAL 活动需要多方面的方法，包括监控、配置调优和适当的维护程序。

1. 启用和监控 WAL 归档

WAL 归档是管理磁盘空间和启用 PITR 的最关键机制。启用归档后，已完成的 WAL 文件将被复制到一个单独的位置（例如，网络文件共享、S3 存储桶或不同的磁盘）。

配置：

修改您的 postgresql.conf 文件：

wal_level = replica         # 或 logical 用于逻辑复制
archive_mode = on           # 启用归档
archive_command = 'cp %p /path/to/archive/%f'

# 使用 wal-g 或类似工具进行 S3 归档的示例：
# archive_command = 'wal-g wal-push %p'
  • %p：用于归档的 WAL 文件的完整路径的占位符。
  • %f：WAL 文件名的占位符。

重要提示： archive_command 必须能够成功执行。如果它返回非零退出代码，PostgreSQL 将认为归档失败，这可能导致 WAL 文件无法被移除。请确保目标目录有足够的空间，并且运行 PostgreSQL 的用户具有写入权限。

监控归档：

使用 SQL 查询检查归档状态：

SELECT archived_count, failed_count FROM pg_stat_archiver;

SELECT pg_current_wal_lsn() AS current_lsn,
       pg_walfile_name_offset(pg_current_wal_lsn()) AS current_wal_file,
       pg_last_wal_replay_lsn() AS replay_lsn; -- 在备用服务器上

-- 检查尚未归档的 WAL 文件（可能表明存在问题）
SELECT pg_wal_lsn_segments(pg_current_wal_lsn() - pg_last_archived_wal_lsn()) AS segments_since_last_archive;

2. 管理 pg_wal 目录大小

即使启用了归档，如果 WAL 段在归档后未被移除，主服务器上的 pg_wal 目录仍会增长。这发生在以下情况：

  • 备用服务器未能跟上，且 wal_keep_size（或对于槽，max_slot_wal_keep_size）设置太小，无法保留足够的 WAL。
  • 复制槽一直保留着 WAL 文件。

wal_keep_size (PostgreSQL 13 之前)

主服务器上的此参数指定了必须保留在 pg_wal 目录中的 WAL 数据量（以 MB 为单位），用于流复制。如果备用服务器落后太远，且追赶所需的 WAL 量超过了 wal_keep_size，则备用服务器可能无法重新连接。

# postgresql.conf on primary
wal_keep_size = 1024 # 在磁盘上保留 1GB 的 WAL

注意： wal_keep_size 是一种历史方法。对于可靠的复制，通常首选使用复制槽。

max_slot_wal_keep_size (PostgreSQL 13 及更高版本)

这是使用复制槽时管理 WAL 保留的首选方法。它限制了所有复制槽总共可以保留的 WAL 磁盘空间总量（以 MB 为单位）。

# postgresql.conf on primary
max_slot_wal_keep_size = 2048 # 限制槽保留 2GB 的 WAL

# 另需考虑：wal_keep_size -- 仍与非槽式流复制相关
# wal_keep_size = 1024 # 为非槽式流复制保留 1GB

如果活动槽所需的 WAL 总量超过了 max_slot_wal_keep_size，即使新 WAL 文件已被槽消费，它们也不会被移除，从而导致磁盘被填满。此参数可防止因有问题的槽导致 WAL 无限制积累。

复制槽

复制槽对于防止 WAL 丢失和确保可靠复制至关重要。但是，如果管理不当，它们也会导致 WAL 文件积累。

  • 问题： 创建了一个复制槽，但消费者（备用服务器或逻辑客户端）断开连接或失败，且该槽从未被删除。主服务器将保留该槽正在等待的所有 WAL 文件。
  • 解决方案： 定期监控复制槽并删除任何不再使用的槽。
-- 列出复制槽
SELECT slot_name, plugin, slot_type, active, wal_status FROM pg_replication_slots;

-- 删除未使用的槽
SELECT pg_drop_replication_slot('slot_name_to_drop');

警告： 删除复制槽将导致任何连接的消费者失去其位置。在删除之前，请确保不再需要该消费者或已对其进行了适当的重新初始化。

3. 调整 min_wal_size 和 max_wal_size

这些参数控制 PostgreSQL 预分配的 WAL 的最小和最大量。虽然它们不会直接导致 WAL 生成量高涨，但它们会影响在高活动期间由于预分配导致 pg_wal 目录增长的速度。

  • min_wal_size：保证至少有这么多的 WAL 空间可用，从而防止频繁的预分配。设置得太低可能导致 pg_wal 目录频繁扩展。
  • max_wal_size：PostgreSQL 将维护的 WAL 的最大量。超出此限制的旧段一旦不再被归档或复制需要，就会被回收或移除。
# postgresql.conf
min_wal_size = 1GB
max_wal_size = 4GB

增加 max_wal_size 可以在高峰写入负载期间为系统提供更大的余地，但这这也意味着更多的磁盘空间将被预分配的 WAL 文件占用。

4. 定期清理归档的 WAL 文件

WAL 归档虽然对恢复至关重要，但如果归档文件从未被清理，也可能导致磁盘空间问题。您必须制定一个策略来管理归档 WAL 文件的保留期。

  • 策略： 实施脚本或使用专用工具（如 pg_archivecleanup、pgBackRest、wal-g、barman）从归档位置移除不再用于 PITR 或复制的旧 WAL 文件。

  • 使用 pg_archivecleanup：
    此实用程序可以在主服务器上运行，以从归档目录中移除旧 WAL 文件。
    bash # 在主服务器上，位于 PostgreSQL bin 目录下： pg_archivecleanup /path/to/archive/location <timelineID> <lsn_to_keep_until>
    或者，它可以集成到您的 archive_command 中（尽管这不太常见且可能比较棘手）。

    更常见的方法是安排 pg_archivecleanup 定期运行，保留 WAL 文件直到上次成功备份的时间点。

    ```bash

    运行每日 cron 任务的示例，保留 24 小时内的 WAL 文件

    确保这与您的备份策略保持一致！

    0 0 * * * pg_archivecleanup -d -v /path/to/archive/location
    ```

    重要提示： 始终确保您的清理策略与您的备份和恢复时间点恢复 (PITR) 要求保持一致。您需要保留足够长时间的 WAL 文件来覆盖所需的恢复窗口。

5. 监控磁盘空间和 WAL 生成速率

主动监控是防止磁盘空间耗尽的关键。

  • 监控磁盘空间： 使用系统监控工具（例如 Nagios、Prometheus、Zabbix）来跟踪数据目录和归档位置的可用空间。

  • 监控 WAL 生成： 查询 pg_stat_wal_receiver（在备用服务器上）和 pg_stat_archiver（在主服务器上）以了解 WAL 活动和归档成功情况。

    ```sql
    -- 检查 WAL 生成速率（近似值）
    SELECT pg_size_pretty(pg_current_wal_lsn()::bigint - pg_last_wal_write_lsn()::bigint) AS current_wal_written;

    -- 检查 WAL 文件年龄
    SELECT pg_walfile_name(f.path) AS wal_file, pg_wal_file_name(f.path) < pg_current_wal_lsn() AS is_old
    FROM pg_ls_dir('/path/to/your/pg_wal') AS f(path)
    ORDER BY f.path;
    ```

磁盘已满时的故障排除步骤

如果您的磁盘因 WAL 活动而已经满了，则需要立即采取行动：

  1. 确定原因： 检查 pg_stat_archiver 是否存在归档失败。检查 pg_replication_slots 中是否有未使用或有问题的槽。检查备用服务器上的复制延迟。
  2. 腾出空间（临时措施）：
    • 如果归档已启用且正在工作： 尝试手动移除一些您确定不再需要的非常旧的归档 WAL 文件（请务必小心）。
    • 如果归档未启用或失败： 如果可能，您可能需要暂时将已完成的 WAL 文件从 pg_wal 移动到另一个磁盘；或者，如果您有备份，请考虑重新初始化数据库（这是一个极端的措施）。
  3. 解决根本原因：
    • 修复归档： 确保 archive_command 正确且目标位置有空间。
    • 管理槽： 删除任何未使用的复制槽。
    • 修复复制： 解决导致备用服务器延迟的问题。
    • 增加磁盘空间： 临时或永久增加更多存储空间。
  4. 重启归档器（如果卡住）： 有时归档器进程可能会卡住。重启 PostgreSQL 可能会有帮助，但请确保您了解其影响。

结论

高 WAL 活动是 PostgreSQL 环境中的一个常见挑战，通常源于高强度的写入操作或复制和归档方面的问题。通过认真启用和监控 WAL 归档、使用 max_slot_wal_keep_size 和 wal_keep_size 正确配置保留策略、管理复制槽，并对归档 WAL 文件实施稳健的清理策略，您可以有效地防止磁盘空间耗尽，并维护一个健康、可靠的 PostgreSQL 数据库。主动监控仍然是预防这些问题的最佳防御措施。