PostgreSQL 为什么Archive 缓慢或不归档,问题的原因在哪里

POSTGRESQL 中是可以对日志进行ARCHIVE 的, 但经常会有一个问题就是ARCHIVE 的速度好像经常没有产生WAL 日志的速度快,有的时候很长一段时间WALLOG 都没有被ARCHIVE, 原因是什么.

我们需要明确的postgresql 的几个点

postgresql 功能是通过一个个进程实现的, walwriter 是写入WAL LOG的进程, 而 archiver 主要是进行archive 归档工作的进程.

则如果你发现系统不归档,请确认你的archiver 的进程是否还在正常的工作.

这里粗略的总结了一下WAL LOG 生成到归档到 archive 目录的一个流程,如有错误还请指正.

所以说如果不能正常归档,的另一个原因是系统并没有进行正常的备份导致不能归档.

以一个例子开始,下面是我们的WAL 目录,我们看一下当前我们的日志写到了那个日志的文件

select pg_walfile_name(pg_current_wal_lsn());

通过语句我们可以知道当前的WAL LOG 已经写到了  (注释: 文件的名字与 lsn号有关,是基于LSN号码), 时间线 + LOGID + LOGSEG  三个部分组成的

000000010000000200000003

pg_controldata -D /pgdata/data/ | grep Latest | grep REDO

通过上面的命令也可以获得我们的当前的额 wal file 和 REDO 的 LSN 信息

那么我们回到题目的问题,到底为什么没有归档,或归档缓慢

1  没有备份

我们通过备份后

可以发现,在设置归档正确的情况下,备份后,会触发归档的操作.

并且在 archive_status 可以获取到目前归档的状态,到了那里.

2  设置保留日志

在postgresql 中 设置了 wal_keep_segments 可以帮助保留一定的wal log 保证复制的过程中,如果standby  节点失败后的,重新建立,保证有一定的日志去恢复standby节点追索数据.

那必然不超过保留的wal log  文件是要保留在pg_wal 目录中的,这点是需要注意的

3  一些想不到的因素

如果说是一个小系统的在PG数据库上,遇到意想不到因素的可能性比较小,但如果是,我们的POSTGRESQL 系统建立在一个比较频繁对数据库进行DML操作的系统,并且并发量也大, 磁盘系统I/O 存在性能的问题,此时你的关注点,就需要看看 调用ARCHIVE COMMAND 的时候,是否会让系统处于无响应的情况,因为PG 调用的命令是外部命令,你可以写任何的方式的方法,来将那些符合的WAL LOG 移动到 ARCHIVE 目录, 但WAL 日志太多,拷贝本身也可能积累, 或者ARCHIVE命令因为拷贝的数据太多,导致"罢工". 那这就属于意想不到的因素范畴了.

实际上归档的过程中,在archive_status 中需要归档的文件是有两个状态的,文件名 + read (准备要备份) 和文件名 + done 的状态, 说明归档完毕了,如果在操作的过程中,调用失败,则系统会等待 1秒后,在此尝试调用外部的命令.

4  设计不当导致的问题

这里的设计的不当指的是归档的命令的选择和归档文件的目的地的选择,

1 归档的系统的文件系统,不要太差,有些设计当中归档的磁盘性能过于底下,导致拷贝的速度很慢, 影响生产系统

2 归档的命令通过网络方式传输,实际当中,这样的做法也是有的,但不建议,因为如果网络出现问题,则需要重试,或者因为网络的带宽的问题导致归档缓慢.

实际上POSTGRESQL 归档这个问题,在小系统上不是问题,而在大型的应用的系统中,应该被重视到底ARCHIVE 这个问题该怎么应对和设计.