PostgreSQL 数据库归档最近被问及的问题问题 与 4 毋 处世学

开头还是介绍一下群，如果感兴趣PolarDB ,MongoDB ,MySQL ,PostgreSQL ,Redis, Oceanbase, Sql Server等有问题，有需求都可以加群群内，可以解决你的问题。加群请联系 liuaustin3 ，（共1790人左右 1 + 2 + 3 + 4 +5） 4群（300+ 到350将关闭自由申请）,另欢迎 OpenGauss 的技术人员加入。

在开始文章前，本人应邀参加12月28日的一场分享活动，这里做做广告。

还是老规矩，技术加生活，先说技术，后说生活的感悟和人生的学习。

在PostgreSQL 中很少被提及的一个问题，归档，而这里经常有人问这个问题，所以需要写一期来说说关于ARCHIVE 的问题。

首先我们需要提出几个问题，

1 为什么要归档，PG中归档了什么

2  什么时间进行归档，归档的原理与频率

3  要怎么在PG中进行归档，归档的方式

在开始研究我们的archive 的问题时我们需要先把archive的知识拉平

首先在pg_wal目录中的日志本身，至少会维护一个当前正在写入的文件，日志中记录了操作中对于数据库的全部更改项，这里需要注意在 archive关闭的状态下，他会将不再使用WAL文件重命名来和重新利用数据库

问题1 ，在PG中WAL日志作为数据库中最核心的日志与保障数据库数据安全的方法，在运行中会产生大量的WAL日志，这里其中包含FULLPAGE  导致的WAL 过大的问题，一般来讲我们认为日志本身的内容占据WAL的数据的内容的30%，而FULL PAGE 的部分占据70%左右的数据，所以PG的WAL归档是一个必须的操作，即时的解决你的磁盘空间重复利用的问题。

在归档中，有一个问题，关于如何触发 archive，这里主要有几点

1   当前的 wal 被写满，并且产生了新的wal文件

2  手动通过pg_switch_wal 来进行数据库的产生新的PG_WAL 文件并且在产生新的PG_WAL 文件后，会对老的WAL 文件产生归档的触发条件。

3  自动设置超时时间archive_timeout 参数并reload 后，到时间会强行进行产生 pg_wal的工作，并且对数据的wal 进行归档。

所有产生数据归档的触发点很多，总结一点产生wal  文件的时候就会触发归档命令。

这里还有一些细节

1 归档如果失败，则归档会持续的被触发，错误日志中会记录归档失败的信息。

2  归档中因为某些原因可以设置， wal_keep_size来解决一些关于日志被归档后，但日志在物理复制中还未被应用而导致的复制中断的问题。

postgres=# show wal_keep_size;

 wal_keep_size 

---------------

 0

(1 row)

3 基于归档的的方式方法，postgresql给出的是一个开放性的方案，在这样的方案中，数据库并没有设定具体怎么去归档，这里比如有传统的方案，S3方案，或者脚本的方案等等，所以归档这个事情是需要自行进行设计和根据自己的情况来进行安排的。

4  在归档中，会出现一些问题，比如数据库恢复后，在进行归档发现归档文件中已经有这个文件了，那么归档必然失败，所以需要手动处理一下，将重复的文件进行清理，然后就可以正常归档了。

5  archive timeout 不要设置的太短，太短会强制产生PG-WAL 文件这些文件都会被填充值，造成PG_WAL膨胀的厉害。

通过命令可以查看当前正在使用的日志文件

SELECT pg_walfile_name(pg_current_wal_lsn());

test=# SELECT pg_walfile_name(pg_current_wal_lsn());
     pg_walfile_name      
--------------------------
 000000010000000000000003
(1 row)

这里PG通过pg_wal/archive_status 来进行数据的归档判断，并且归档进程每60秒进行一次尝试工作，调用pgarch_archivercopyloop() 来处理每个等待处理的WAL 段，通过archive_command 来进行数据的归档的处理

但归档的问题主要出在一个部分，就是归档中如何判断要进行下一个文件的归档，这里是通过archive_status 来进行判断的，但这里的问题是，每次需要对文件夹里面的文件进行一个遍历如果这里面的文件很多的情况下，会阻碍归档文件流程中的性能。

这里PG15对这个问题进行了梳理和解决，他们根据将文件名保存到数组的放方式来进行判断下一个需要进行归档的文件是那个。

其中的流程是

扫描 archive_status 目录，然后将需要进行归档的日志放到一个数组中，并且将信息提供给archive_command命令或模块，这样减少在目录中扫描的的数量，但仍会发生目录扫描，并存在相关的O(n^2)复杂度。

 通过这项改进，在社区的测试报告中，提到在这项上面提高了20多倍的性能。

写到这里并没有完，实际上我们在数据归档后还需要对归档后的文件进行清理，大多数的情况下，清理归档文件是通过手动，通过归档文件的日期来进行清理，利用磁盘空间和存储有效的数据归档文件。

在一些场合下，比如你没有使用一些高级的备份软件的情况下，你的数据归档最后的清理和留存可能会需要 pg_archivecleanup 命令来进行清理，pg_archivecleanup 本身没是一个非常小的，独立的单个文件，不需要利用postgresql 服务器，源代码400行，他的功能主要有以下函数来完成

initialize , TrimExtension, CleanupPriorWALFile, 

SetWALFileNameForCleanup

初始化是在数据库中调用函数并检测程序初始化中的对象是否是一个文件夹，如果不是则直接报错，同时TrimExtension是将该函数目录的每个文件的后缀都去掉，方便进行以主名来进行数据的清理， CleanupPriorWalFile 函数通过获得对应的wal 的文件名来将进行比较，比当前文件在早的文件都会被清理，这里通过setWalFileNameForCleanup 来进行数据的名的获取。

如果希望pg_archivecleanup 独立工作，可以通过如下的命令来设置，但这里首先需要获得正确的archivelocation的目录。

archive_cleanup_command = 'pg_archivecleanup archivelocation %r'

参考文章：

https://www.percona.com/blog/speed-up-of-the-wal-archiving-in-postgresql-15/

————————————————————————————

最近一直在除了持续学习数据库技术外，提高自己的认知的维度，4毋是最近和冯老师学到的，毋意，毋必，毋固， 毋我

1 毋意： 不要臆想，不要你认为，你觉得，你习惯，你不是事情的核心，庄子：且夫水之积也不厚，则其负大舟也无力，如果你做事，看书，经历不够广，那么你做的事情不能保证大概率在当时当下是对的。

2 毋必：  没有什么是绝对的，包含名人名言，要时刻保持清晰的思考，判断，认知是有局限的。

3 毋固： 没有什么事情是不能进行转换变通的，不要故步自封，不要过早的下结论，对事情在一开始就存在固有的开发和定义，不与时俱进，并同步最新的知识。

4 毋我： 做事不要以自己为中心，要以事情为中心，如何将事情完成好，是关键，而不是把自己摆到事情的前面，为了脸面，为了所谓的自尊