postgresql 手动清理wal日志的101个坑

2024-02-11 06:44
文章标签 日志 postgresql 清理 手动 101 wal

本文主要是介绍postgresql 手动清理wal日志的101个坑，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

       新年的第一天，总结下去年遇到的关于WAL日志清理的101个坑，以及如何相对安全地进行清理。前面是关于WAL日志堆积的原因分析，清理相关可以直接看第三部分。

       首先说明，手动清理wal日志是一个高风险的操作，尤其对于带主从的生产大库，能不用尽量不要用。

一、 常见的WAL 堆积原因

       其实之前有总结过（第8题） 《PostgreSQL面试题集锦》学习与回答-CSDN博客

      去年遇到的两次都是因为WAL日志生成量过大，而pg 10中归档进程又仅支持单进程串行归档，下面单独列一下这个问题。

二、 PG 10中WAL日志归档的瓶颈

1. 归档流程

每当WAL日志切换时，就可以通知对该日志进行归档：

  • 产生日志切换的进程在pg_wal/archive_status下生成与待归档日志同名的.ready文件
  • 发送信号通知archiver process（我们是pgbackrest的archive push），其只关心是否有.ready文件存在，不关心其内容
  • archiver process（pgbackrest的archive push）按照archive_command进行日志归档
  • 执行完成后，archiver process循环将.ready文件重命名为.done文件

2. 归档的瓶颈

       由于我们使用的是pgbackrest，在上面步骤中，前三步都可以并行完成，唯独第四步，需要靠archiver process单独工作（pg 15版本引入了新特性，可以64个文件为一组进行操作）。

/** pgarch_ArchiverCopyLoop** Archives all outstanding xlogs then returns*/
static void
pgarch_ArchiverCopyLoop(void)
{char        xlog[MAX_XFN_CHARS + 1];/** 循环处理.ready文件*/while (pgarch_readyXlog(xlog)){int         failures = 0;int         failures_orphan = 0;for (;;){struct stat stat_buf;char        pathname[MAXPGPATH];…/* 进行日志归档 */if (pgarch_archiveXlog(xlog)){/* successful，归档成功，将.ready改为.done文件 */pgarch_archiveDone(xlog);/** Tell the collector about the WAL file that we successfully archived*/pgstat_send_archiver(xlog, false);/* 开始处理下一个日志 */break;          /* out of inner retry loop */}/* 归档失败  */
...}}
}

在WAL日志量不大，archive_status中文件不多时，循环查找文件并重命名是很快的，经观察：

  • 在archive_status中约5000个文件时，archiver process每秒可以处理8~10个.ready文件
  • 而在问题期间，archive_status中日志多达百万个，每次循环异常耗时，每秒仅能处理3~4个.ready文件（对应每小时约168~225G WAL日志）
  • 在业务高峰期，每小时产生WAL日志基本都在200G以上，有时高达400G，远远高于其处理速度，导致archive_status目录中堆积文件更多，处理速度更慢
  • 由于archiver process进程处理速度远远落后pgbackrest执行的archive_command命令，pgbackrest也认为自己无需再工作，因此未再启动

         在pg中，只有已经归档的WAL日志（生成.done文件的）才能被回收或删除，由于归档速度过慢，导致可以被清理的WAL日志很少，而新增的WAL日志量又很大，最终导致WAL日志堆积，/data目录剩余空间持续下降。

...if (XLogArchiveCheckDone(xlde->d_name)){/* Update the last removed location in shared memory first，首先在共享内存中更新已被删除的位置 */UpdateLastRemovedPtr(xlde->d_name);/* 调用RemoveXlogFile函数进行删除或重命名，函数里使用unlink删除日志 */RemoveXlogFile(xlde->d_name, recycleSegNo, &endlogSegNo);}
...

三、 WAL日志清理的101个坑

1. WAL日志的重命名

       非常危险的一点，概括而言，pg会将最旧的一些wal日志重命名为最新的名字，但利用ll -rth排序查看时，其时间并不会变化。而pg_archivecleanup工具只根据文件名进行判断，很可能导致需要的文件被删除。具体分析参考postgresql源码学习（58）—— 删除or重命名WAL日志？这是一个问题、-CSDN博客

       如下图，实际上FE和FF结尾的文件是重命名后的，但显示的时间并没有变化，按时间排序还是在最上面。

① 主库需要的日志被删除

这是最危险的情况，可能导致：

  • 主库crash：在某些情况下，可能会由于数据不一致或者持续性错误导致主库宕机。这点目前没有测试出来，但风险肯定是存在的。
  • 主库crash后无法启动：删除wal日志后kill pg进程即可复现，结合前一点，如果主库真的异常崩溃，很可能根本都无法启动

不幸中的万幸主库还活着，也存在以下风险：

  • 主库数据丢失：未写入磁盘的事务可能会丢失，因为相关的WAL日志已经被删除。
  • 数据不一致：如果已经提交的事务所对应的 WAL 日志被删除，那么这些事务的修改可能无法被正确地应用到从库上，从而导致数据不一致。
  • 主从同步中断：相当于从库需要的日志被删除
  • 旧备份无法恢复到最新状态：理论上建议立即发起一个全备，因为之前的备份链已经断了

来整点高危操作模拟一下，测试版本为pg 14

  • 删除正在用的WAL日志，主库是否会crash
  • 删除正在用的WAL日志，正常停库，能否启动
  • 删除正在用的WAL日志，kill pg进程，能否启动

查看主库当前在用的wal日志

-bash-4.2$ pg_controldata
…
Latest checkpoint's REDO WAL file:    0000000500000008000000FD

试试将其删除会发生什么

可以看到pg进程还在（当然不保证每次都会还在）

造点数据执行checkpoint，会发现它重新生成了FD的文件，但其实原来文件里的数据已经丢失了。

挪走FD文件，尝试正常停库再启动

发现能起来，并且它切换到了用FE文件

挪走FE文件，kill pg进程再启动，这下悲剧了

看看日志报错

这只能走点更极端的路子，把pg_wal给reset掉，影响当然就更大了

pg_resetwal -f /data/postgres/pg5432/data

② 从库需要的文件被删除
  • 导致主从中断，由于pg原生不支持并行备份，大库的搭建耗时耗力。
  • 如果主库生成的wal日志量非常大（例如每天TB级），那更是雪上加霜，甚至需要停主库业务来搭建。

③ 新特性

       在pg 12中，新增了wal_recycle参数，可以关闭wal日志的重命名，并且不需重启生效。虽然引入的原因是在COW文件系统中新建日志会更快，但也在很大程度上规避了误删wal日志的风险。

2. 孤儿.ready文件

这部分特别感谢熊灿灿老师帮忙一起分析，又学到不少新知识：

小心！孤儿归档也可能将数据库整死！

① pg 12之前

       如果你只删除wal日志，会导致其对应的.ready变成孤儿文件，归档进程归档失败，会反复尝试处理第一个失败的wal日志，最终的结果就是wal日志仍然无法归档，出现堆积，空间被占满。

       以pg 10为例，相关代码如下。可以看到如果归档失败，它只会sleep一段时间然后重试，并不做额外处理，因此日志中会一直看到archiving write-ahead log file failed too many times, will try again later 的报错

static void
pgarch_ArchiverCopyLoop(void)
{char        xlog[MAX_XFN_CHARS + 1];/** loop through all xlogs with archive_status of .ready and archive* them...mostly we expect this to be a single file, though it is possible* some backend will add files onto the list of those that need archiving* while we are still copying earlier archives*/while (pgarch_readyXlog(xlog)){int         failures = 0;for (;;){/** Do not initiate any more archive commands after receiving* SIGTERM, nor after the postmaster has died unexpectedly. The* first condition is to try to keep from having init SIGKILL the* command, and the second is to avoid conflicts with another* archiver spawned by a newer postmaster.*/if (got_SIGTERM || !PostmasterIsAlive())return;/** Check for config update.  This is so that we'll adopt a new* setting for archive_command as soon as possible, even if there* is a backlog of files to be archived.*/if (got_SIGHUP){got_SIGHUP = false;ProcessConfigFile(PGC_SIGHUP);}/* can't do anything if no command ... */if (!XLogArchiveCommandSet()){ereport(WARNING,(errmsg("archive_mode enabled, yet archive_command is not set")));return;}if (pgarch_archiveXlog(xlog)){/* successful */pgarch_archiveDone(xlog);/** Tell the collector about the WAL file that we successfully* archived*/pgstat_send_archiver(xlog, false);break;          /* out of inner retry loop */}else{/** Tell the collector about the WAL file that we failed to* archive*/pgstat_send_archiver(xlog, true);if (++failures >= NUM_ARCHIVE_RETRIES){ereport(WARNING,(errmsg("archiving write-ahead log file \"%s\" failed too many times, will try again later",xlog)));return;     /* give up archiving for now */}pg_usleep(1000000L);    /* wait a bit before retrying */}}}
}

② 新特性

       pg 12开始引入了一个检查，如果归档过程中发现仅有.ready文件，而没有对应wal日志，pg会在日志输出一条告警并删除这个.ready文件。

       以pg 14为例，它新增了一段代码

if (stat(pathname, &stat_buf) != 0 && errno == ENOENT){char        xlogready[MAXPGPATH];StatusFilePath(xlogready, xlog, ".ready");if (unlink(xlogready) == 0){ereport(WARNING,(errmsg("removed orphan archive status file \"%s\"",xlogready)));/* leave loop and move to the next status file */break;}if (++failures_orphan >= NUM_ORPHAN_CLEANUP_RETRIES){ereport(WARNING,(errmsg("removal of orphan archive status file \"%s\" failed too many times, will try again later",xlogready)));/* give up cleanup of orphan status files */return;}/* wait a bit before retrying */pg_usleep(1000000L);continue;

3. 孤儿wal文件会有什么效果

       因为archive process的效率依赖于archive_status目录中的.ready文件数，当时还想了个办法——如果我不清wal日志，只把.ready mv走会怎么样？

       事实证明是不可行的，pg检查到wal日志没有.ready文件后，会给它重新生成一个对应的.ready文件，然后开始给它做归档，相当于归档是正常进行的。

四、 如何相对安全地手动清理wal日志

1. 准备工作

① pg 12及以上版本

整体操作是类似的，但对于高版本pg，相当于还有两道保险操作

  • 设置 wal_recycle 为off，调整不用重启，可以极大地避免误删除风险

  • wal日志和.ready文件不要求完全对齐

        虽说12版本开始pg会自动清理孤儿.ready文件，但当堆积量太大时，归档进程处理效率会极其低下，等它一个个报错清也要到猴年马月。不过好处是可以不必完全对齐，差个几十几百的，pg也能自己给你处理了。

② pg 12之前版本

      这就得靠自己了，我们准备了以下几道保险：

  • 与业务沟通停写入业务，尽量减少wal日志产生量。
  • 查看主从库当前在用的wal日志，待清理日志必须小于这个日志号。

以下图为例，主库当前发送的日志是1759xxxx，那么删除时，我们最多只删1758xxx的日志号

  • 以文件修改时间和文件名共同作为删除条件

       当wal日志被重命名后，虽然ll -rth查看其时间未变，但stat命令可以看到其change time和modify time都是变化的。因此我们实际应该用ll -rcth排序，查看最旧的日志名。

       理论上知道这个特点后，用pg_archivecleanup按文件名分批清理也是可以的，并且速度更快。但安全起见我们还是用find命令，以ctime,mtime,name条件共同限制

ll -crth |grep  0000000300174|more
ll -cth |grep  0000000300174|more
ll -cth |grep  0000000300174|wc -l# 输出结果
Jan 29 04:55 - 10:29   0000000300174*
  • 输出待清理的文件名
find /data/postgres/pg5432/data/pg_wal -maxdepth 1 -mtime +0 -ctime +0 -name "0000000300174*" -exec ls -lhc {} \; > /tmp/old_wal_174.txt

检查输出的文件名及时间是否符合预期

2. 正式清理

  • 业务停写入操作
  • 停pgbackrest
pgbackrest stop
  • 删除对应wal日志
find /data/postgres/pg5432/data/pg_wal -maxdepth 1 -mtime +0 -ctime +0 -name "0000000300174*" -exec rm -rf {} \;
  • 挪走对应.ready文件

        这步若是使用find+rm，在文件量大时耗时过长，例如24万个文件，find+rm耗时超过15分钟，而mv在1分钟内可完成。

mkdir -p /data/postgres/pg5432/data/pg_wal/archive_status_bak0129
cd /data/postgres/pg5432/data/pg_wal/archive_status
mv 0000000300174*ready ../archive_status_bak0129/
  • 循环执行以上步骤，直至删完待清理文件
  • 启动pgbackrest
pgbackrest start
ps -ef|grep pgbackrest
  • 检查archiver process

应该开始处理剩余的wal日志并且逐步推进（正常每秒10个以上），没有报错

ps -ef|grep archiver
  • 检查.ready文件数，应该逐渐减少
cd /data/postgres/pg5432/data/pg_wal/archive_status
ll -h |grep  ready|wc -l
  • 检查wal日志数，应该逐渐减少
cd /data/postgres/pg5432/data/pg_wal/
ll -h |wc -l
  • 启动应用

一段时间后.ready文件及wal日志数应该能稳定在一个水平线而非持续走高，以我们的库为例，大概在7000个wal日志，120G左右

  • 新增告警线

新加了wal目录大小的监控及告警，及时发现日志堆积问题，尽早处理

select sum((pg_stat_file(file)).size) from (select dir||'/'||pg_ls_dir(dir) as file from (select setting as dir from pg_settings where name='log_directory') t)t where (pg_stat_file(file)).change>=current_date;

这篇关于postgresql 手动清理wal日志的101个坑的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！


http://www.chinasem.cn/article/699112。

相关文章

flume系列之：查看flume系统日志、查看统计flume日志类型、查看flume日志

flume系列之：查看flume系统日志、查看统计flume日志类型、查看flume日志

遍历指定目录下多个文件查找指定内容 服务器系统日志会记录flume相关日志 cat /var/log/messages |grep -i oom 查找系统日志中关于flume的指定日志 import osdef search_string_in_files(directory, search_string):count = 0
阅读更多...
我在移动打工的日志

我在移动打工的日志

客户：给我搞一下录音 我：不会。不在服务范围。 客户：是不想吧 我：笑嘻嘻（气笑） 客户：小姑娘明明会，却欺负老人 我：笑嘻嘻 客户：那我交话费 我：手机号 客户：给我搞录音 我：不会。不懂。没搞过。 客户：那我交话费 我：手机号。这是电信的啊！！我这是中国移动！！ 客户：我不管，我要充话费，充话费是你们的 我：可是这是移动！！中国移动！！ 客户：我这是手机号 我：那又如何，这是移动！你是电信！！
阅读更多...
PostgreSQL核心功能特性与使用领域及场景分析

PostgreSQL核心功能特性与使用领域及场景分析

PostgreSQL有什么优点？ 开源和免费 PostgreSQL是一个开源的数据库管理系统，可以免费使用和修改。这降低了企业的成本，并为开发者提供了一个活跃的社区和丰富的资源。 高度兼容 PostgreSQL支持多种操作系统（如Linux、Windows、macOS等）和编程语言（如C、C++、Java、Python、Ruby等），并提供了多种接口（如JDBC、ODBC、ADO.NET等
阅读更多...
PostgreSQL中的多版本并发控制（MVCC）深入解析

PostgreSQL中的多版本并发控制（MVCC）深入解析

引言 PostgreSQL作为一款强大的开源关系数据库管理系统，以其高性能、高可靠性和丰富的功能特性而广受欢迎。在并发控制方面，PostgreSQL采用了多版本并发控制（MVCC）机制，该机制为数据库提供了高效的数据访问和更新能力，同时保证了数据的一致性和隔离性。本文将深入解析PostgreSQL中的MVCC功能，探讨其工作原理、使用场景，并通过具体SQL示例来展示其在实际应用中的表现。 一、
阅读更多...
Detectorn2预训练模型复现：数据准备、训练命令、日志分析与输出目录

Detectorn2预训练模型复现：数据准备、训练命令、日志分析与输出目录

Detectorn2预训练模型复现：数据准备、训练命令、日志分析与输出目录 在深度学习项目中，目标检测是一项重要的任务。本文将详细介绍如何使用Detectron2进行目标检测模型的复现训练，涵盖训练数据准备、训练命令、训练日志分析、训练指标以及训练输出目录的各个文件及其作用。特别地，我们将演示在训练过程中出现中断后，如何使用 resume 功能继续训练，并将我们复现的模型与Model Zoo中的
阅读更多...
SSM项目使用AOP技术进行日志记录

SSM项目使用AOP技术进行日志记录

本步骤只记录完成切面所需的必要代码 本人开发中遇到的问题： 切面一直切不进去，最后发现需要在springMVC的核心配置文件中中开启注解驱动才可以，只在spring的核心配置文件中开启是不会在web项目中生效的。 之后按照下面的代码进行配置，然后前端在访问controller层中的路径时即可观察到日志已经被正常记录到数据库，代码中有部分注释，看不懂的可以参照注释。接下来进入正题 1、导入m
阅读更多...
多数据源的事务处理总是打印很多无用的log日志

多数据源的事务处理总是打印很多无用的log日志

之前做了一个项目，需要用到多数据源以及事务处理，在使用事务处理，服务器总是打印很多关于事务处理的log日志（com.atomikos.logging.Slf4jLogger），但是我们根本不会用到这些log日志，反而使得查询一些有用的log日志变得困难。那要如何屏蔽这些log日志呢？ 之前的项目是提高项目打印log日志的级别，后来觉得这样治标不治本。 现在有一个更好的方法： 我使用的是log
阅读更多...
android两种日志获取log4j

android两种日志获取log4j

android   log4j 加载日志使用方法； 先上图： 有两种方式： 1：直接使用架包 加载（两个都要使用）； 架包：android-logging-log4j-1.0.3.jar 、log4j-1.2.15.jar  （说明：也可以使用架包：log4j-1.2.17.jar）  2：对架包输入日志的二次封装使用； 1:直接使用 log4j 日志框架获取日志信息： A:配置 日志 文
阅读更多...
PostgreSQL入门介绍

PostgreSQL入门介绍

一、PostgreSQL 背景及主要功能介绍 1、背景 PG数据库，全称为PostgreSQL数据库，是一款开源的关系型数据库管理系统（RDBMS）。其起源可以追溯到20世纪80年代末和90年代初，由加拿大的计算机科学家Michael Stonebraker及其团队在加州大学伯克利分校启动。该项目旨在创建一个强大的、开源的关系型数据库管理系统，作为早期关系型数据库系统Ingres的继承者。Mi
阅读更多...
Unity Post Process Unity后处理学习日志

Unity Post Process Unity后处理学习日志

Unity Post Process Unity后处理学习日志 在现代游戏开发中，后处理（Post Processing）技术已经成为提升游戏画面质量的关键工具。Unity的后处理栈（Post Processing Stack）是一个强大的插件，它允许开发者为游戏场景添加各种视觉效果，如景深、色彩校正、辉光、模糊等。这些效果不仅能够增强游戏的视觉吸引力，还能帮助传达特定的情感和氛围。 文档
阅读更多...

Copyright China编程 23002807@qq.com

沪ICP备2023033072号-2