[翻译]PostgreSQL中的WAL压缩以及版本15中的改进

yzsDBA

发布于 2023-02-26 13:08:36

1.3K0

发布于 2023-02-26 13:08:36

[翻译]PostgreSQL中的WAL压缩以及版本15中的改进

从以开始就一直在尝试对WAL进行不同级别的压缩。自2016年以来内置功能（wal_compression）就一直存在，几乎所有备份工具都会在传递到备机前对WAL进行压缩。但现在是时候再看看内置的wal_compression功能了。因为PG15提供了更多功能。如果我们将其与PG15中WAL归档的其他重大改进相结合，将会有相当大的收益，如之前贴子PG15中的新WAL归档模块/库：

https://www.percona.com/blog/new-wal-archive-module-library-in-postgresql-15/

以及PG15中的WAL归档加速：

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

这里并不打算通过备份工具查看WAL段文件压缩，因为它是一个PG外部工具，主要是备份工具的一个功能，即使我们不使用专门的备份工具，我们仍然可以将WAL段文件作为归档的一部分进行压缩，这可以获得很大回报。

先看下PG内部为WAL压缩提供了什么。在将整页写入WAL时启动WAL压缩功能，这将节省大量IO开箱。减小WAL段文件大小在复制和备份方面有进一步的好处，毕竟需要传输的数据更少了嘛。

什么是全页写？

新手用户可能想了解啥是“Full Page Writes”，PG默认使用8KB页面。

postgres=# show block_size ;
block_size
------------
8192
(1 row)

但是主机可能正在处理更小的页面，比如 4k 页面。

$ getconf PAGESIZE
4096

PG将8KB页作为读写的“原子单位”来处理。但由于主机的页面较小，它会拆分8KB页面，并将每个OS页面视为一个原子单位。如果突然中断，会导致问题：8KB页面的一部分可能已保存，而另一部分可能会丢失。因为主机可能不会将后者视为原始部分的一部分。这就是通常说的“部分页面写入”或“撕裂页面”。

从数据库的角度来看，这种“损坏的页面”是损坏的。如果存在具有这种撕裂页面的数据文件，PG将失去页面的一致性。当然，这不仅仅是PG的问题，每个数据库软件都需要处理整个问题。例如MySQL/InnoDB使用doublewrite缓冲区处理此问题，恢复时从doublewrite恢复未损坏页面的副本。PG解决这个问题的方法略有不同。该副本在检查点后首次修改时，PG将完整页面的副本写入WAL有日志中。由于WAL周期性同步，并且PG也可以决定在哪个点进行恢复，因此WAL是一个安全的地方用于保存“整页”副本。

全页写的性能损失

如上所述，当数据库页面在检查点之后第一次被修改时，需要将其安全地写入 WAL。因此在崩溃恢复期间，PostgreSQL 可以安全地应用来自 WAL 日志的一致页面。但这会带来相当大的性能影响。

现在我们知道在一个检查点之后很有可能会立即进行过多的整页写入。这将在 PostgreSQL性能基准测试中清晰可见，作为Vadim 在他的测试中观察到的“锯齿波”模式：

正如我们所看到的，由于大量 WAL 写入，吞吐量在每个检查点之后突然下降，然后逐渐回升，直到下一个检查点。

全页压缩和改进

PG14及其之前的版本全页更大并且包含所有内容。允许在写入WAL段文件之前压缩那些完整的页面。这个特性在PG9.5就出现了，使用内置的LZ压缩实现，通常称为“pglz”。但由于CPU开销，并不受欢迎。所以并不建议使用。可以使用如下命令启用：

ALTER SYSTEM SET wal_compression=ON;
SELECT pg_reload_conf();

现在的压缩算法开始提供更好的压缩，同时占用更少的CPU周期。Lz4就是一个很好的例子。PG15针对wal_compression增加了枚举值：pglz、lz4、zstd。以及向后兼容的on和off。on,true,yes和1等布尔等效于“pglz”。

与 PostgreSQL中内置的压缩库 pglz 不同，新的压缩功能由外部库提供。因此需要在编译时启用它们。配置标志–with-lz4和–with-zstd分别用于 lz4 和 zstd。

对于repositories中安装的预编译安装包，可以使用下面命令来检查：

/usr/pgsql-15/bin/pg_config | grep "zstd\|lz4"
CONFIGURE = '--enable-rpath' '--prefix=/usr/pgsql-15' '--includedir=/usr/pgsql-15/include' '--mandir=/usr/pgsql-15/share/man' '--datadir=/usr/pgsql-15/share' '--libdir=/usr/pgsql-15/lib' '--with-lz4' '--with-extra-version= - Percona Distribution' '--with-zstd' '--with-icu' '--with-llvm' '--with-perl' '--with-python' '--with-tcl' '--with-tclconfig=/usr/lib64' '--with-openssl' '--with-pam' '--with-gssapi' '--with-includes=/usr/include' '--with-libraries=/usr/lib64' '--enable-nls' '--enable-dtrace' '--with-uuid=e2fs' '--with-libxml' '--with-libxslt' '--with-ldap' '--with-selinux' '--with-systemd' '--with-system-tzdata=/usr/share/zoneinfo' '--sysconfdir=/etc/sysconfig/pgsql' '--docdir=/usr/pgsql-15/doc' '--htmldir=/usr/pgsql-15/doc/html' 'CFLAGS=-O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fexceptions -fstack-protector-strong -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection' 'LDFLAGS=-Wl,--as-needed' 'LLVM_CONFIG=/usr/bin/llvm-config' 'CLANG=/usr/bin/clang' 'PKG_CONFIG_PATH=:/usr/lib64/pkgconfig:/usr/share/pkgconfig' 'PYTHON=/usr/bin/python3'
LIBS = -lpgcommon -lpgport -lselinux -lzstd -llz4 -lxslt -lxml2 -lpam -lssl -lcrypto -lgssapi_krb5 -lz -lreadline -lpthread -lrt -ldl -lm