【PostgreSQL】PostgreSQL的WAL日志归档的压缩
作者:互联网
随着硬件和软件的发展,数据库的瓶颈也发生了转移。很多老的问题可能消失了,也有新的问题出来了。
老的限制
以前是CPU和内存受到限制。十多年前,4核服务器是“高端”服务器,作为DBA,我最担心的是管理可用资源。Oracle尝试使用RAC架构为单个数据库从多个主机集中CPU和内存是解决这个问题的一个很好的尝试。
然后是存储速度限制的日子。它是由多核多线程处理器变得普遍引发的,以及内存大小和总线速度的增加。企业试图通过复杂的SAN驱动器、带有缓存的专用存储等来解决它。但它已经存在很多年了,即使是现在企业开始越来越多地转向NVMe驱动器。
最近我们开始观察到一个新的瓶颈,它正在成为许多数据库用户的痛点。随着单主机服务器能力的提高,它开始处理大量事务。有些系统可以在几分钟内生成数千个WAL文件,并且有一些案例,其中WAL归档到更便宜、更慢的磁盘系统无法赶上WAL生成。许多组织更喜欢在低带宽网络上存储WAL档案,更增加了复杂性。(Postgres Archiving 有一个固有的问题,如果它落后,它往往会滞后更多,因为归档过程需要在.ready 文件中搜索。这里不讨论)
在本文中,我想提请你注意一个事实,如果还没有压缩 WAL的话,WAL压缩是很容易实现的。以及一个用于监控归档gap的查询。
压缩PostgreSQL WALs
归档前压缩WAL的需求与日俱增。幸运的是,大多数PostgreSQL备份工具(如pgbackrest/wal-g等)已经实现了。archive_command调用这些工具,为用户静默存档。
例如,在pg_backrest 中,我们可以指定archive_command,它在后台使用gzip进行压缩:
ALTER SYSTEM SET archive_command = 'pgbackrest --stanza=mystanza archive-push %p';
或者WAL-G工具,使用lz4进行压缩:
ALTER SYSTEM SET archive_command = 'WALG_FILE_PREFIX=/path/to/archive /usr/local/bin/wal-g wal-push %p';
如果我们没有使用任何备份工具,而想压缩归档呢?
我们仍然可以使用Linux提供的如gzip、bzip等进行压缩。比如:
alter system set archive_command = '/usr/bin/gzip -c %p > /home/postgres/archived/%f.gz';
然而,7za是所有WAL压缩选项中最有趣的,它尽可能快地提供最高压缩比。可以显式安装7za,它是来自7zip包的一部分。
在centos7上:
sudo yum install epel-releasesudo yum install p7zip
在ubuntu上:
sudo apt install p7zip-full
安装后就可以使用了:
postgres=# alter system set archive_command = '7za a -bd -mx2 -bsp0 -bso0 /home/postgres/archived/%f.7z %p'; ALTER SYSTEM
在我的测试系统中,可以看到小于200kb的归档WAL文件。大小根据WAL的内容而有所不同,这取决于数据库上的事务类型。
-rw-------. 1 postgres postgres 197K Feb 6 12:13 0000000100000000000000AA.7z -rw-------. 1 postgres postgres 197K Feb 6 12:13 0000000100000000000000AB.7z -rw-------. 1 postgres postgres 198K Feb 6 12:13 0000000100000000000000AC.7z -rw-------. 1 postgres postgres 196K Feb 6 12:13 0000000100000000000000AD.7z -rw-------. 1 postgres postgres 197K Feb 6 12:13 0000000100000000000000AE.7z
将16MB文件压缩到千字节范围内肯定会节省网络带宽和存储空间,同时解决归档落后的问题。
还原WALs
归档和获得最高压缩只是其中的一部分,但我们也应该能够在需要时恢复它们。备份工具提供自己的恢复命令选项。例如,pgbackrest可以使用 archive-get :
restore_command = 'pgbackrest --stanza=demo archive-get %f "%p"'
WAL-G提供了wal-fetch选项来执行相同的工作。
如果选择使用gzip手动压缩归档,我们可以在restore_command中使用gunzip程序,如下所示:
gunzip -c /home/postgres/archived/%f.gz > %p
从postgresql12开始,可以使用alter system命令修改:
postgres=# alter system set restore_command = 'gunzip -c /home/postgres/archived/%f.gz > %p'; ALTER SYSTEM
对于7za,可以这样:
postgres=# alter system set restore_command = '7za x -so /home/postgres/archived/%f.7z > %p'; ALTER SYSTEM
但是,与archive_command更改不同,restore_command更改需要重新启动standby数据库。
监控归档进程活动
当前WAL归档可从pg_stat_archiver.status获得,但使用WAL文件名找出gap有点棘手。我用来找出WAL归档滞后的示例查询是这样的:
select pg_walfile_name(pg_current_wal_lsn()),last_archived_wal,last_failed_wal, ('x'||substring(pg_walfile_name(pg_current_wal_lsn()),9,8))::bit(32)::int*256 + ('x'||substring(pg_walfile_name(pg_current_wal_lsn()),17))::bit(32)::int - ('x'||substring(last_archived_wal,9,8))::bit(32)::int*256 - ('x'||substring(last_archived_wal,17))::bit(32)::int as diff from pg_stat_archiver;
这里需要注意的是,当前的WAL和要归档的WAL具有相同的时间线,以便此查询能够正常工作,这是常见的情况。我们很少会遇到与生产中不同的情况。因此,在监视PostgreSQL服务器的WAL归档时,此查询可能会有很好的帮助。
标签:wal,PostgreSQL,postgres,WAL,command,归档,archive 来源: https://www.cnblogs.com/abclife/p/16437581.html