pg_wal文件过多过大清理方式

• pg_wal文件过多过大
  

• 如果 PostgreSQL 中的 pg_wal 文件过多或过大，可能是由于以下原因：

  1. 数据库写入负载过大：如果你的数据库有大量的写入操作，会导致 pg_wal 文件的增长速度很快。
  2. 备份和复制延迟：如果你的数据库设置了基于 WAL 的备份或复制，但备份或复制操作无法及时进行， pg_wal 文件可能会被积累。

  下面是一些处理 pg_wal 文件过多或过大的方法：

  1. 检查数据库写入负载：如果写入负载过高，可能需要优化数据库操作和查询。优化查询可以减少写入操作和 WAL 日志的生成。
  2. 备份和复制：确保备份和复制操作正常运行，当备份或复制操作延迟时， pg_wal 文件可能会增长过快。如果备份或复制操作无法及时进行，可以考虑调整备份策略或增加备份和复制的资源。
  3. 增加磁盘空间：如果 pg_wal 文件过多导致磁盘空间不足，可以考虑增加磁盘空间。
  4. 调整 WAL 日志的相关设置：你可以通过调整 WAL 相关的设置来限制 pg_wal 文件的大小和数量。例如，max_wal_size 和 min_wal_size 参数用于调整 WAL 日志分段的大小，max_wal_keep_size 参数用于限制保存的 WAL 日志段数。
  5. 压缩和归档旧的 WAL 日志：可以考虑使用 pg_repack 工具对 WAL 日志进行压缩和归档，以释放磁盘空间。

  请注意，在处理 pg_wal 文件之前，建议先备份数据库以防意外发生。

• PostgreSQL版本为13.5，如何高效安全的清理一些不必要的pg_wal中的文件
  

• 在 PostgreSQL 13.5 中，为了高效且安全地清理不必要的 pg_wal 文件，你可以执行以下步骤：

  1. 确认数据库和备份的完整性：在清理 WAL 文件之前，确保数据库和备份是完整和可用的，以防需要进行恢复。

  2. 检查当前 WAL 文件的使用情况：运行以下查询来检查当前 WAL 文件使用的情况：

     SELECT * FROM pg_stat_bgwriter;
     

     注意关注 buffers_alloc、buffers_backend 和 buffers_backend_fsync 字段，这些字段显示了 WAL 缓冲区的使用情况。

  3. 停止写入操作：在清理 WAL 文件之前，最好先停止写入操作，以确保不会有新的 WAL 文件生成。

  4. 备份并测试恢复：在进行任何修改之前，请先备份数据库，并测试能够成功恢复到备份点。

  5. 设置合适的参数：根据你的需求，可以设置以下参数来控制 WAL 文件的大小和保留数量。

     • max_wal_size：这是一个动态参数，用于设置 WAL 日志分段的大小。可以根据数据库写入负载和可用磁盘空间来适当调整该参数。
     • min_wal_size：这是一个动态参数，用于控制 WAL 日志分段的最小大小。设置一个合适的值可以确保保留足够的 WAL 文件供应急恢复使用。
     • archive_command：这是一个用于归档 WAL 文件的命令。可以根据需要配置以将旧的 WAL 文件归档到其他位置。

  6. 清理 WAL 文件：执行以下操作清理不必要的 WAL 文件。

     • 使用 pg_archivecleanup 工具：如果你在 archive_command 中设置了归档命令，并将旧的 WAL 文件归档到其他位置，可以使用 pg_archivecleanup 工具清理掉不再需要的旧文件。例如：

       pg_archivecleanup <归档目录路径> <开始清理的 WAL 文件名>
       

       其中 <归档目录路径> 是归档目录的路径，<开始清理的 WAL 文件名> 是要保留的最新 WAL 文件的名称。

     • 手动删除 WAL 文件：如果你没有设置归档命令，或者想要手动删除一些 WAL 文件，可以按以下步骤进行：

       • 停止 PostgreSQL 实例。
       • 在 $PGDATA/pg_wal/ 目录中删除不再需要的 WAL 文件。请谨慎删除，确保不删除正在使用的文件和必要的历史文件。
       • 启动 PostgreSQL 实例。

  请注意，在进行任何修改之前，请务必备份数据库并测试恢复过程。清理 WAL 文件具有一定的风险，所以请务必小心操作。

PostgreSQL的循环覆盖写是通过把旧的WAL日志“重命名”来实现的。发生一次Checkpoint之后，此Checkpoint点之前的WAL日志文件都可以删除，而PostgreSQL中一般并不会将其删除，而是“重命名”旧的WAL文件使之成为一个新的WAL文件。所以WAL文件目录下文件序号最大的那个WAL文件并不是当前正在写的WAL文件，因为这个WAL文件有可能是前一次Checkpoint时重命名旧文件产生的。我们用一个示例来说明这种情况。

序号最大的文件名为“00000001000000000000002B”，接下来我们进到数据库中，查看当前正在写的文件是哪一个：

select pg_walfile_name(pg_current_wal_lsn());

pg_walfile_name
--------------------------
  000000010000000000000027
(1 row)

上面的SQL语句中先用函数“pg_current_wal_lsn”获得当前正在写的LSN号，然后用函数“pg_walfile_name”找出当前LSN号对应的WAL文件，发现是“000000010000000000000027”说明这时“000000010000000000000028”“000000010000000000000029”“00000001000000000000002A”“00000001000000000000002B”都是以前的WAL文件。