开头还是介绍一下群，如果感兴趣polardb ,mongodb ,mysql ,postgresql ,redis 等有问题，有需求都可以加群群内有各大数据库行业大咖，CTO，可以解决你的问题。加群请联系 liuaustin3 ，在新加的朋友会分到3群（共810人左右 1 + 2 + 3），这里需要注意，如果想和 瑞典马工进行面对面的交流的同学，可以单独提出申请加入 3群,否则如2群。

正文

相信不少人对于PG的归档方式进行过吐槽，比如为什么用CP 命令是PG默认归档的方式等等这样的问题。主要被吐槽的问题

效率低下：传统的 PostgreSQL 使用 shell 命令进行 WAL（Write Ahead Log）归档，这导致了大量不必要的操作和低效性。

文档误导：PostgreSQL 文档给出一个将 test 和 cp 命令结合在一起的不安全命令作为示例，许多用户照搬这种方法，导致归档问题的发生。

备份工具：在过去，用户需要依赖第三方备份工具，如 PgBackRest，来解决归档问题。

那么PG15 给我们带来了什么，带来了基于归档方式的变化，PostgreSQL 为连续归档提供了创建自定义模块的基础设施，自定义归档模块会更加稳定和高效。

当配置了自定义archive_library时，PostgreSQL 将完成的 WAL 文件提交给该模块，服务器将避免回收或删除这些 WAL 文件，直到模块指示文件已成功归档。这里PG15提供了一个basic_archive 的基础归档模块，通过ba 可以简单的将需要归档的日志进行数据的迁移。

根据官方文档，我们可以通过以下的几部来配置一个basic_archive 的归档的工作。

可以看到，我们的归档在通过base_archive 的方式进行归档后，我们并未在archive_command 中进行归档的命令的设置，而是通过basic_archive模块来进行归档。这样的归档方式的优势是

它创建一个临时文件，并在目标位置将其 fsync 并持久地移动到最终的存档文件副本中。这种持久性是 cp 无法提供的。这大大降低了存档目标中损坏文件导致存档失败，甚至有时会导致数据库可恢复性的可能性。

basic_archive 的另一个重要功能优势是，当源（pg_wal）和存档目标中存在相同文件时，它具有内置功能来比较两者。它比较文件的内容并验证它们完全相同，然后向存档器报告“成功”，以便存档进程可以继续处理下一个 WAL 分段。这也降低了存档失败的机会。因为如果文件由模块存档，但在记录之前服务器崩溃，PostgreSQL将尝试再次存档相同的 WAL 分段。如果文件已复制并具有相同的内容，新的 basic_archive 模块示例会在第二次尝试时静默成功。

另外有些同学提出在加载时报错，这里需要注意，basic_archive 是在需要进行编译的，否则是无法进行加载的，所有必须对contrib 的模块的进行编译和安装，才能使用这个功能。

当然很多人可能认为，这个方式和之前的方式比较并未有很大的改变，但是这是一个好的开始，基于PG15对于归档模块的注意和改变，未来可能有新的模块来参与到PG的归档工作中，或许有更强大的第三方的公司来开发归档模块，这对于一些 企业版的PG 厂商来说也是一个好的事情，我们都希望PG 数据库的功能越来越完善，越来越稳定。