网站开发所得税,企业管理培训课程是不是传销,苏州企业管理咨询服务,外链发布工具下载新年的第一天#xff0c;总结下去年遇到的关于WAL日志清理的101个坑#xff0c;以及如何相对安全地进行清理。前面是关于WAL日志堆积的原因分析#xff0c;清理相关可以直接看第三部分。 首先说明#xff0c;手动清理wal日志是一个高风险的操作#xff0c;尤其对于带主从的… 新年的第一天总结下去年遇到的关于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 processpgbackrest的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 checkpoints 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 well 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);}/* cant 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文件 这步若是使用findrm在文件量大时耗时过长例如24万个文件findrm耗时超过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 namelog_directory) t)t where (pg_stat_file(file)).changecurrent_date;
