PostgreSQL trim_error 报错问题排查和远程快速修复经验分享

PostgreSQL trim_error 报错问题排查和远程快速修复经验分享

前段时间,我们线上一个核心业务数据库突然出现了大量的“trim_error”报错，导致部分写入操作失败，情况比较紧急，由于是远程运维，不能直接登录服务器，所以整个排查和修复过程都是在线上完成的，下面我就把这次处理的经验分享一下，希望能给遇到类似问题的朋友一些参考。

问题现象

最开始是监控系统报警,显示数据库的写操作错误率飙升，我们立刻登录到数据库管理平台，查看错误日志，在日志里，清晰地看到了很多条包含“trim_error”关键字的报错信息，具体的错误信息大概是说，在尝试清理（trim）某个WAL（预写日志）文件时发生了错误。（来源：线上PostgreSQL错误日志）

这个错误不是业务SQL语法错误,而是数据库底层存储层面的一个异常，所以它直接影响的是事务的提交，导致用户感觉“系统卡住了”或者“提交失败”。

初步排查思路

看到“trim_error”和WAL相关，我们首先想到的是不是磁盘空间出了问题，因为WAL日志在事务提交后，如果不再需要，就会被“修剪”或“回收”，以便腾出空间给新的日志文件使用，如果这个过程失败，很可能是磁盘没有空间了，或者文件系统权限不对。

1. 检查磁盘空间：我们立刻通过运维工具远程查看了数据库服务器上数据目录所在的磁盘分区，结果发现，磁盘使用率确实已经超过了95%，但还没有到100%完全写满的地步，这说明磁盘空间紧张是诱因，但可能不是直接原因，因为理论上还留有一点空间。（来源：通过df -h命令检查）
2. 检查WAL日志目录：我们接着检查了存放WAL日志的pg_wal目录（在老版本中可能是pg_xlog），使用du -sh命令查看目录大小，发现它异常巨大，远远超过了我们平时设置的max_wal_size，这表明WAL日志的清理机制确实没有正常工作，导致旧日志堆积，撑大了磁盘空间。
3. 检查文件系统权限：我们顺带用ls -l命令检查了pg_wal目录及其内部文件的属主和权限，确认都是PostgreSQL的运行用户，权限设置正确，排除了权限问题的可能性。

深入分析与定位根本原因

既然磁盘没满、权限也对，为什么trim会失败呢？我们开始查阅PostgreSQL的官方文档和相关技术资料。（来源：PostgreSQL官方文档关于WAL配置和管理的章节）

通过分析,我们了解到一个关键点：PostgreSQL的WAL清理进程（checkpointer）在尝试删除旧的WAL文件时，如果文件正在被其他进程使用（比如一个延迟的归档操作，或者一个尚未结束的流复制连接），那么删除操作就会失败，并抛出“trim_error”，这通常发生在系统负载很高、或者归档/复制链路出现延迟或故障的情况下。

我们立刻检查了相关的进程和配置：

1. 检查归档状态：我们使用了pg_stat_archiver这个系统视图来查看WAL日志的归档状态，果然，发现last_failed_wal字段显示了最近一个归档失败的WAL文件名，并且failed_count在不断增加，这说明配置的归档命令（比如archive_command）出了故障，导致WAL日志无法被成功归档到备份存储。（来源：通过SQL查询 SELECT * FROM pg_stat_archiver;）
2. 检查复制状态：由于我们这个实例还有只读从库，我们又检查了流复制的状态，使用pg_stat_replication视图，发现其中一个从库的reply_lag（复制延迟）非常大，几乎处于停滞状态，这意味着主库上的WAL日志也无法被这个从库及时消费掉。

根本原因浮出水面：由于归档命令失败（后来查明是备份存储的网络连接不稳定），加上一个从库复制延迟严重，导致一些旧的WAL日志既不能被归档标记为“可删除”，也不能被所有从库确认接收，即使磁盘还有一点点空间，checkpointer进程也不敢擅自删除这些“可能还需要”的WAL文件，最终在尝试清理时因条件不满足而报出“trim_error”。

远程快速修复步骤

定位到原因后,我们制定了快速修复方案，目标是先恢复系统正常写入，再解决根本问题。

1. 紧急释放磁盘空间（治标）：

   • 我们首先尝试清理一些非关键的临时日志文件,但释放的空间有限。
   • 更有效的方法是,谨慎地手动清理一些肯定已经不需要的旧WAL日志，我们使用pg_archivecleanup工具，并指定一个比当前最早需要的WAL文件更早的文件名进行清理。注意：这个操作有风险，必须确保删除的文件确实不被需要，最好在有备份的前提下进行。（来源：PostgreSQL工具手册pg_archivecleanup）
   • 清理后,磁盘使用率降到了85%左右，很快，监控显示“trim_error”报错迅速减少并消失，系统写入功能恢复正常。

2. 解决根本问题（治本）：

   • 修复归档：我们检查了归档脚本和网络配置，修复了到备份存储的网络连接问题，并重启了归档进程，观察到pg_stat_archiver中的failed_count不再增长，归档恢复正常。
   • 处理复制延迟：我们检查了延迟从库的状态，发现是查询负载过重导致，我们先将该从库重启，暂时断开其复制连接，让主库可以快速清理积压的WAL日志，规划后续对该从库进行硬件升级或优化查询。
   • 调整参数预防：我们适当增大了max_wal_size参数，为系统在遇到短暂延迟时提供了更大的缓冲空间，加强了归档和复制链路的监控告警。

经验总结

这次远程处理“trim_error”的经历，让我们深刻认识到：

• 监控是关键：不仅要监控磁盘空间，更要监控WAL目录大小、归档状态、复制延迟等深层指标。
• “trim_error”往往是表象，根源通常是归档失败、复制延迟、磁盘空间不足等多个因素共同作用的结果。
• 在紧急情况下,手动清理WAL是快速恢复的有效但高风险的手段，务必小心确认。
• 远程运维要熟练掌握各种命令行工具和SQL查询,才能快速定位问题。
• 预防胜于治疗,确保归档和复制等高可用组件的稳定可靠，是避免此类问题的根本。