PostgreSQL 常见配置参数及相关命令

一、PostgreSQL常见配置参数

max_wal_size :

两个检查点(checkpoint)之间,WAL可增长的最大大小,即:自动WAL checkpoint允许WAL增长的最大值。

该值缺省是1GB。如果提高该参数值会提升性能,但也是会消耗更多空间、同时会延长崩溃恢复所需要的时间。

注意:这个参数是个软限制,不是硬限制,因此实际WAL可能会超过这个值(如:较大的 wal_keep_segments 设置)。

min_wal_size :

检查点(checkpoint)后用来保留的,用于未来循环使用的WAL文件。可以被用来确保有足够的WAL空间被保留来应付WAL使用的高峰,以供将来的检查点使用。这可以用来确保预留足够的WAL空间处理WAL使用中的峰值,比如当运行大批量工作时。

如果PG空闲时,会逐渐将WAL量减少到 min_wal_size。

该值缺省是80MB。请不要将该值设置的太小。

查看数据库 min_wal_size & max_wal_size 参数配置:

testdb01=> select name, setting, unit, short_desc from pg_settings where name like '%wal_size%';

max_wal_size | 1024 | MB | Sets the WAL size that triggers a checkpoint.

min_wal_size | 80 | MB | Sets the minimum size to shrink the WAL to.

也可以执行:

testdb01=> show max_wal_size;

1GB

testdb01=> show min_wal_size;

80MB

testdb01=>

PostgreSQL开启归档:

step1:修改 postgresql 的配置文件(postgresql.conf)、开启归档

wal_level = replica # minimal, replica, or logical. 根据实际业务设置wal记录日志级别

archive_mode = on # 默认为off关闭,on代表开启归档

archive_command = '' # command to use to archive a logfile segment. 归档操作执行的命令,如果开启归档,必须配置归档命令、否则不会归档

几种归档命令配置方式:

archive_command = 'test ! -f /mnt/server/pg_archive/%f && cp %p /mnt/server/pg_archive/%f' # Unix

archive_command = 'copy "%p" "C:\\server\\pg_archive\\%f"' # Windows

archive_command = 'rsync -a %p postgres@[SOME_OTHER_HOST]:/data/pg_archive/%f' # rsync 增量方式远程归档

archive_command ='scp %p postgres@[SOME_OTHER_HOST]:/data/pg_archive/%f' #

我配置为:

archive_command = 'test -f /var/lib/pgsql/12/data/pg_archive/archive_active && test ! -f /var/lib/pgsql/12/data/pg_archive/%f && cp %p /var/lib/pgsql/12/data/pg_archive/%f'

也可以配置成下面这种,是等效的:

archive_command = 'test ! -f /var/lib/pgsql/12/data/pg_archive/archive_active || (test ! -f /var/lib/pgsql/12/data/pg_archive/%f && cp %p /var/lib/pgsql/12/data/pg_archive/%f)'

另外,如果想要按照每天一个日期目录进行归档,则可以配置为:

archive_command = 'DATE=`date +%Y%m%d`;DIRBASE="/var/lib/pgsql/12/data/pg_archive";DIR="$DIRBASE/$DATE";test -f $DIRBASE/archive_active && (test -d $DIR || mkdir -p $DIR) && test ! -f $DIR/%f && cp %p $DIR/%f'

%p:是指相对路径

%f:是指文件名

更多WAL预写日志配置相关的参数介绍,参考官方文档:

http://postgres.cn/docs/10/runtime-config-wal.html#RUNTIME-CONFIG-WAL-CHECKPOINTS

step2:创建归档路径

mkdir -p $PGDATA/pg_archive

touch $PGDATA/pg_archive/archive_active #为了方便控制、配合归档命令设置了归档开关,通过该文件是否存在来控制是否执行归档

chown -R postgres:postgres $PGDATA/pg_archive

step3:重启数据库

step4:验证归档是否正常

$ ls -l $PGDATA/pg_archive && echo ">>>>" && ls -l $PGDATA/pg_wal

total 0

-rw-r--r-- 1 postgres postgres 0 Feb 27 11:35 archive_active

>>>>

total 32768

-rw------- 1 postgres postgres 16777216 Mar 3 13:17 000000010000000000000002

-rw------- 1 postgres postgres 16777216 Feb 27 11:05 000000010000000000000003

drwx------ 2 postgres postgres 6 Feb 27 10:31 archive_status

-bash-4.2$

$ pg_controldata

pg_control version number: 1201

Catalog version number: 201909212

Database system identifier: 7204657628260517886

Database cluster state: in production

pg_control last modified: Fri 03 Mar 2023 01:17:05 PM CST

Latest checkpoint location: 0/284FE48

Latest checkpoint's REDO location: 0/284FE10

Latest checkpoint's REDO WAL file: 000000010000000000000002

Latest checkpoint's TimeLineID: 1

$ psql -Upostgres

postgres=# checkpoint;

CHECKPOINT

postgres=# select pg_switch_wal(); -- pg10.0之前版本对应命令为 select pg_switch_xlog();

pg_switch_wal

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

0/284FFF8

(1 row)

postgres=# exit

-bash-4.2$ ls -l $PGDATA/pg_archive && echo ">>>>" && ls -l $PGDATA/pg_wal

total 16384

-rw------- 1 postgres postgres 16777216 Mar 7 09:47 000000010000000000000002

-rw-r--r-- 1 postgres postgres 0 Feb 27 11:35 archive_active

>>>>

total 32768

-rw------- 1 postgres postgres 16777216 Mar 7 09:47 000000010000000000000002

-rw------- 1 postgres postgres 16777216 Mar 7 09:47 000000010000000000000003

drwx------ 2 postgres postgres 43 Mar 7 09:47 archive_status

-bash-4.2$

-bash-4.2$ pg_controldata

pg_control version number: 1201

Catalog version number: 201909212

Database system identifier: 7204657628260517886

Database cluster state: in production

pg_control last modified: Tue 07 Mar 2023 09:46:15 AM CST

Latest checkpoint location: 0/284FF30

Latest checkpoint's REDO location: 0/284FEF8

Latest checkpoint's REDO WAL file: 000000010000000000000002

Latest checkpoint's TimeLineID: 1

WAL空间使用情况:

如果日志量大于 max_wal_size,则WAL日志空间尽量保持在 max_wal_size 。因为会触发检查点,不需要的段文件将被移除直到系统回到这个限制以下。

如果日志量小于 max_wal_size,则WAL日志空间至少保持 min_wal_size。可以被用来确保有足够的WAL空间被保留来应付WAL使用的高峰,以供将来的检查点使用。

通常情况下,WAL日志空间大小在 min_wal_size ~ max_wal_size 之间动态评估。该估计基于在以前的检查点周期中使用的WAL文件数的动态平均值。如果实际使用量超过估计值,动态平均数会立即增加。

-bash-4.2$ cd $PGDATA

-bash-4.2$ du -sh pg_wal && ls -lh pg_wal/

1.2G pg_wal

total 1.2G

-rw-------. 1 postgres postgres 16M Feb 6 09:20 000000010000000000000001

-rw-------. 1 postgres postgres 16M Feb 14 19:04 000000010000000000000002

-rw-------. 1 postgres postgres 16M Feb 14 19:04 000000010000000000000003

-rw-------. 1 postgres postgres 16M Feb 14 19:04 000000010000000000000004

-rw-------. 1 postgres postgres 16M Feb 14 19:04 000000010000000000000005

......

-rw-------. 1 postgres postgres 16M Feb 14 19:11 00000001000000000000003E

-rw-------. 1 postgres postgres 16M Feb 14 19:11 00000001000000000000003F

-rw-------. 1 postgres postgres 16M Feb 14 19:11 000000010000000000000040

-rw-------. 1 postgres postgres 16M Feb 14 19:12 000000010000000000000041

-rw-------. 1 postgres postgres 16M Feb 14 19:12 000000010000000000000042

-rw-------. 1 postgres postgres 16M Feb 14 19:12 000000010000000000000043

-rw-------. 1 postgres postgres 16M Feb 14 19:12 000000010000000000000044

-rw-------. 1 postgres postgres 16M Feb 14 19:12 000000010000000000000045

-rw-------. 1 postgres postgres 16M Feb 14 19:12 000000010000000000000046

-rw-------. 1 postgres postgres 16M Feb 14 19:12 000000010000000000000047

drwx------. 2 postgres postgres 6 Dec 6 2021 archive_status

-bash-4.2$

pg_wal大小至少保留 80MB 的文件,也就是 000000010000000000000001~47 所有文件至少保留 80MB

执行checkpoint以后,pg_wal大小可能会降低到 max_wal_size 以内,多次执行checkpoint不一定会降低到 min_wal_size,这还处决于很多其他配置和因素。

关于checkpoint

checkpoint:

A checkpoint is a point in the write-ahead log sequence at which all data files have been updated to reflect the information in the log. All data files will be flushed to disk.

checkpoint是WAL(write-ahead log)日志中的一个位点,在这个点位之前数据库中的所有数据都和WAL日志中反映的信息相同,也就是说该位点之前所有 Shared Buffer 中的脏页均已被刷入到存储磁盘。

checkpoint 是一个名词,同时也是一个动词,执行一个 checkpoint SQL操作,会往 WAL 日志里写 checkpoint 位点。checkpoint SQL命令的官方介绍参考:http://postgres.cn/docs/10/sql-checkpoint.html

数据库什么时机会进行checkpoint操作

1)超级用户手动执行checkpoint命令;

2)checkpoint_timeout 配置参数中指定的间隔到达(默认300秒);

3)写入WAL的数据量(du -sh $PGDATA/pg_wal)已达到参数 max_wal_size(默认值:1GB),软限制、实际可能会超出;

4)online backup 开始的时候;

5)pg_start_backup 执行时;

6)数据库实例关闭时;

7)CREATE/DROP DATABASE等数据库配置操作时;

执行checkpoint时,数据库主要完成以下几个工作:

1)识别Shared Buffers中所有的脏页;

2)将脏页写入相应的数据文件;

3)确保修改后的文件通过fsync()写入到磁盘。

PostgreSQL 写数据的过程:

以 INSERT INTO test01 VALUES(1); 为例,写数据的流程如下:

step1:将 INSERT 1 这个操作写入 WAL 日志中。 WAL 日志是物理日志,记录的是对某个文件某个块的修改。

step2:修改 Shared Buffer 中该页的信息(如果该页不在 Buffer 中,则从磁盘去取),test01表中写入1。此时如果有表的读取则直接读取Shared Buffer返回数据。

step3:background writer 写磁盘(disk)。background 进程会在某个时刻将 Shared Buffer 中的数据刷到磁盘。但是这并不是立刻发生的,而是一个异步操作。

PostgreSQL数据库checkpoint & 故障恢复

如果上面step3过程中出现故障、background wirter 写磁盘失败了,那么PostgreSQL重启会进入恢复模式,会基于上次 checkpoint点位和 WAL(Redo) 日志进行重放,从而将数据刷到磁盘。

checkpoint过程

step1:写入checkpoint start日志,该日志中包括所有的活跃Txn;

step2:写入所有dirty的TreeNode(有数据修改,但是没有写入过硬盘的TreeNode是dirty的);

step3:从LeafNode节点开始写,先写子节点,再写入父节点,最后写入根节点;

step4:写入根节点以后,写入checkpoint complete日志。Checkpoint写入完成。

checkpoint 操作过程会往 WAL 日志里写 checkpoint 位点。例如:

WAL: | ... | INSERT 1 | INSERT 2 | ... | INSERT 3 | checkpoint |

|

-> 这里(INSERT 1之后)执行一个checkpoint操作,产生一个 redo point(redo重做位点),从这里开始到checkpoint写入时一个完整的checkpoint过程

checkpoint详细流程如下:

step1:写入checkpoint start日志。checkpoint 操作首先记录下 checkpoint 的开始位置(INSERT 2之后),记录为 redo point(重做位点);

step2:checkpoint 将 Shared Buffer 中的脏数据刷到磁盘里面去,写入所有dirty的TreeNode(有数据修改,但是没有写入过硬盘的TreeNode是dirty的);

step3:这时候数据库又来了一条 SQL:INSERT 3;

step4:checkpoint 刷脏结束,写checkpoint complete日志。redo point 之前的数据均已被刷到磁盘存储(数据1和2);

step5:这时候在 WAL 日志里面记录 checkpoint 位点(INSERT 3后),表明 checkpoint 操作结束。checkpoint 位点会记录相关信息,比如 redo point 的值(从哪开始重做);

step6:将最新的 checkpoint 位点记录在 pg_control 文件中,通过 pg_controldata 可查看控制信息。

从上面的流程可以看出,checkpoint 操作已经能保证将 redo point 位点之前的数据落盘了,那 redo point 之前的所有 WAL 日志都已经没有用了(即使下次故障,这部分数据已经被持久化落盘了,也不需要恢复),就可以请理了。不过有些特殊情况,即使WAL日志已经没有用了,也可能导致不被自动清理,例如创建了流复制插槽但未使用/消费。

故障恢复:

重启时数据库自动进入恢复模式,进行数据恢复。在做数据恢复时:

step1:扫描所有日志,找到最后一个完整的Checkpoint(即:Checkpoint Start日志和Checkpoint Complete日志同时存在)。先找到检查点结束的WAL位置(checkpoint complete位点);

step2:然后根据这里的结束检查点时写入的WAL信息找到开始的位置(redo重做位点);

step3:然后从开始的位置(redo重做位点)开始读取WAL并实施 replay恢复数据,至少要恢复到检查点结束(checkpoint complete)的WAL位置才能保证数据的一致性和完整性。

WAL日志清理:

数据库数据目录下pg_wal的WAL文件在开启归档的模式下,会将已归档WAL文件自动清理删除。

如果开启了归档,在pg_wal/archive_status目录下会有一些文件,以ready结尾的,表示可以归档但还没有归档,以done结尾的表示已经归档。

WAL文件的自动清理流程如下:

转储WAL段文件到disk,写满或者使用 pg_switch_wal() 后,会生成000000xxxx.ready文件,调用archive_command 命令且成功执行后,将ready文件更名为.done文件。而数据库会在执行checkpoint后计算出最旧的需保留的WAL文件,比该值更早的WAL文件均会被清理。

注意:有些情况会导致wal日志不会自动删除。例如下面情况:

1,查看 pg_replication_slots 视图,客户端连接接收到数据的 LSN 还在数据库服务端视图的 confirmed_flush_lsn 列中可用。pg_replication_slots 早于此 LSN 的数据才是不再可用、数据库负责回收磁盘空间,否则不会回收磁盘空间。

2,查看 pg_replication_slots 视图,该 restart_lsn 列包含客户端连接接收可能需要的最旧 WAL 的 LSN。如果 confirmed_flush_lsn 定期增长、且 restart_lsn 滞后,则数据库需要回收空间。

3,查看 pg_replication_slots 视图,如果存在 active 为 false,即:select * from pg_replication_slots where active='f'; 则数据库也不会回磁盘收空间,WAL日志也不会删除。

wal日志文件一直未自动清除:

$ ls -l pg_wal

-rw-------. 1 postgres postgres 16777216 Feb 6 09:20 000000010000000000000001

-rw-------. 1 postgres postgres 16777216 Feb 14 19:04 000000010000000000000002

-rw-------. 1 postgres postgres 16777216 Feb 14 19:04 000000010000000000000003

-rw-------. 1 postgres postgres 16777216 Feb 14 19:04 000000010000000000000004

......

-rw-------. 1 postgres postgres 16777216 Feb 16 19:50 0000000100000000000000BD

-rw-------. 1 postgres postgres 16777216 Feb 16 20:03 0000000100000000000000BE

drwx------. 2 postgres postgres 4096 Feb 16 19:52 archive_status

testdb01=> select * from pg_replication_slots;

slot_name | plugin | slot_type | datoid | database | temporary | active | active_pid | xmin | catalog_xmin | restart_lsn | confirmed_flush_lsn

--------------------+---------------+-----------+--------+----------+-----------+--------+------------+------+--------------+-------------+---------------------

replication_slot01 | test_decoding | logical | 16437 | testdb01 | f | f | | | 590 | 0/180A540 | 0/180A578

replication_slot02 | pgoutput | logical | 16437 | testdb01 | f | f | | | 594 | 0/180C270 | 0/29AA7B0

(2 rows)

-bash-4.2$ pg_controldata

pg_control version number: 1201

Catalog version number: 201909212

Database system identifier: 7038444130751219893

Database cluster state: in production

pg_control last modified: Thu 16 Feb 2023 07:50:04 PM CST

Latest checkpoint location: 0/BC104648

Latest checkpoint's REDO location: 0/B9CCC548

Latest checkpoint's REDO WAL file: 0000000100000000000000B9

Latest checkpoint's TimeLineID: 1

删除没有使用的 replication slot (active = f)以后,手动执行 checkpoint ,会进行WAL空间回收,自动删除部分WAL日志文件:

testdb01=> select pg_drop_replication_slot('replication_slot02');

testdb01=> select pg_drop_replication_slot('replication_slot01');

testdb01=> \c - postgres

Password for user postgres:

You are now connected to database "testdb01" as user "postgres".

testdb01=#

testdb01=# checkpoint;

执行需要一端时间,过程中可以查看wal日志文件不断再减少:

$ ls -l $PGDATA/pg_wal/ | wc -l

shared_buffers:

shared_buffers 是缓存。在数据库系统中,我们主要关注磁盘IO,而且其大多是随机IO,因此从磁盘的读取比较慢,为了解决这个问题,postgresql将数据缓存在内存中,牺牲内存来换取随机读取的性能。

shared_buffers 参数用来设置数据库服务器将使用的共享内存缓冲区量。默认通常是 12MB,但是如果你的内核设置不支持(在initdb时决定),那么可以会更少,但不能小于 128kB。

不过为了更好的性能,通常会使用明显高于最小值的设置。 如果指定值时没有单位(MB等),则以块为单位,即BLCKSZ字节,通常为8kB。此参数只能在服务器启动时设置。

如果服务器内存被数据库专用、服务器内存 >= 1GB,合理的shared_buffers初始值是设置为系统内存的25%。shared_buffers并非越大越好,shared_buffers增大,也会造成一些工作负载。超过内存 40% 反而会不好。

shared_buffers更大的设置通常要求对max_wal_size也做相应增加。生产系统可以根据实际业务需求适当调整该参数。

二、PostgreSQL常用命令

WAL日志及LSN查询:

1.查看视图 pg_replication_slots 信息:

testdb01=> select * from pg_replication_slots ;

slot_name | plugin | slot_type | datoid | database | temporary | active | active_pid | xmin | catalog_xmin | restart_lsn | confirmed_flush_lsn

--------------------+---------------+-----------+--------+----------+-----------+--------+------------+------+--------------+-------------+---------------------

replication_slot01 | test_decoding | logical | 16437 | testdb01 | f | f | | | 590 | 0/180A540 | 0/180A578

replication_slot02 | pgoutput | logical | 16437 | testdb01 | f | f | | | 594 | 0/180C270 | 0/29AA7B0

(2 rows)

2.pg_controldata 查看控制信息:

$ pg_controldata

pg_control version number: 1201

Catalog version number: 201909212

Database system identifier: 7038444130751219893

Database cluster state: in production

pg_control last modified: Fri 10 Feb 2023 02:29:59 PM CST

Latest checkpoint location: 0/29AA700

Latest checkpoint's REDO location: 0/29AA6C8

Latest checkpoint's REDO WAL file: 000000010000000000000002

Latest checkpoint's TimeLineID: 1

Latest checkpoint's PrevTimeLineID: 1

Latest checkpoint's full_page_writes: on

Latest checkpoint's NextXID: 0:626

Latest checkpoint's NextOID: 35373

......

3.查询数据库LSN等信息:

-- PG10以前的版本

select pg_current_xlog_location(),pg_xlogfile_name(pg_current_xlog_location()),pg_xlogfile_name_offset(pg_current_xlog_location());

其中:

pg_current_xlog_location():获得当前wal日志写入位置。

pg_xlogfile_name():转换wal日志位置为文件名。

pg_xlogfile_name_offset():返回转换后的wal日志文件名和偏移量。

-- PG10及以后版本

select pg_current_wal_lsn(),pg_walfile_name(pg_current_wal_lsn()),pg_walfile_name_offset(pg_current_wal_lsn());

testdb01=> select pg_current_wal_lsn(),pg_walfile_name(pg_current_wal_lsn()),pg_walfile_name_offset(pg_current_wal_lsn());

pg_current_wal_lsn | pg_walfile_name | pg_walfile_name_offset

--------------------+--------------------------+-------------------------------------

0/29AA7B0 | 000000010000000000000002 | (000000010000000000000002,10135472)

(1 row)

其中:

pg_current_wal_lsn(): 获得当前wal日志写入位置。

pg_walfile_name(): 转换wal日志位置为文件名。

pg_walfile_name_offset():返回转换后的wal日志文件名和偏移量。

说明

LSN:0/29AA7B0

0:代表wal文件的第二部分

2:代表wal文件的最后两位02

9AA7B0:代表对应日志文件内的偏移量

4.查看pg_wal目录下的日志文件:

$ ls -l $PGDATA/pg_wal

total 32768

-rw-------. 1 postgres postgres 16777216 Feb 6 09:20 000000010000000000000001

-rw-------. 1 postgres postgres 16777216 Feb 10 14:30 000000010000000000000002

drwx------. 2 postgres postgres 6 Dec 6 2021 archive_status

wal文件由三部分组成每个4字节(8个16进制字符)总共12字节24个16进制字符。第一部分(4字节)代表时间线(TimeLineID)、第二部分代表LSN高32位、第三部分代表LSN低32位(LSN低32位的最高两位代表该日志文件的LSN起始编号)。

000000010000000000000002 日志文件名的格式如下:

00000001:第一部分(4字节)代表数据库运行的时间轴,如果恢复过数据库(主备切换)这个值会增大;

00000000:第二部分、LSN高32位;

00000002:第三部分、LSN低32位。其中最高两位为0代表LSN该日志文件的LSN其实编号为0。

根据时间线 00000001 和 0/29AA7B0 可以推算出日志文件为:000000010000000000000002,对位的文件内的偏移为:0x9AA7B0 = 10135472

5.查询当前的最新LSN和WAL文件:

testdb01=> select * from pg_control_checkpoint();

checkpoint_lsn | redo_lsn | redo_wal_file | timeline_id | prev_timeline_id | full_page_writes | next_xid | next_oid | next_multixact_id | next_multi_offset |

oldest_xid | oldest_xid_dbid | oldest_active_xid | oldest_multi_xid | oldest_multi_dbid | oldest_commit_ts_xid | newest_commit_ts_xid | checkpoint_time

----------------+-----------+--------------------------+-------------+------------------+------------------+----------+----------+-------------------+-------------------+-

-----------+-----------------+-------------------+------------------+-------------------+----------------------+----------------------+------------------------

0/29AA700 | 0/29AA6C8 | 000000010000000000000002 | 1 | 1 | t | 0:626 | 35373 | 1 | 0 |

479 | 1 | 626 | 1 | 1 | 0 | 0 | 2023-02-10 14:29:56+08

(1 row)

testdb01=>

WAL(Write Ahead Log)预写日志

WAL(Write Ahead Log)预写式日志,类似于Oracle的Redo日志。区别是Oracle中Redo是配置固定几个Redo日志文件,然后轮着切换去写入。而PostgreSQL中WAL日志是动态切换的,单个WAL日志文件写满后继续写下一个WAL日志文件,连续不断生成很多WAL日志文件。

单个WAL日志文件的大小默认16MB。适当提高单个WAL日志文件的大小会降低磁盘IO操作、性能有一定提升。

PG11.0以下的版本不支持动态调整、而是在编译postgresql时通过参数"--with-wal-segsize"设置,编译后不能修改。

PG11.0及以后的版本支持通过参数"wal_segment_size"动态调整、数据库启动初始化时生效。另外也可以通过initdb配置选项"--with-wal-segsize"来修改配置。

WAL的核心概念是,对数据文件(表和索引所在的地方)的更改必须在写入了日志文件后这些更改之后才可以写入数据文件,也就是说,描述更改的日志记录被刷新到永久存储之后才可以写数据文件。

使用WAL可以显著减少磁盘写操作的数量,因为只需要将日志文件刷新到磁盘以确保提交事务,而不是事务更改的每个数据文件。日志文件是按顺序写入的,因此同步日志的成本要比刷新数据页的成本低得多。

备注:

1)数据库将脏数据刷到数据文件上,这个动作是随机I/O,性能远比写日志文件的顺序I/O差太多。

2)数据库事务:数据库事务在实现的时候,要保证数据落盘成功才能返回。落盘是指落盘到自己的事务日志文件里就返回成功,而不是直接写入到数据库表文件里。原因还是磁盘读写性能问题,事务只要落盘成功就可以,写到哪里不重要。写到一个日志文件中,就是顺序IO,而写到数据文件就变成随机IO了。

3)更多 WAL内部详情(包括故障恢复过程),可参考官方文档说明:http://postgres.cn/docs/10/wal-internals.html

WAL日志归档

1.手动触发WAL日志归档:

select pg_switch_xlog(); -- pg10.0之前的版本

select pg_switch_wal(); -- pg10.0之后的版本

执行手动日志归档以后,WAL会切换到新的日志文件,这时会将老的WAL日志归档。

2.自动WAL日志归档:

1)WAL日志写满后触发自动归档

WAL每个日志文件大小的默认配置是16MB,WAL日志文件写满后切换WAL日志文件,会触发自动归档。

PG11.0以下的版本不支持动态调整、而是在编译postgresql时通过参数"--with-wal-segsize"设置,编译后不能修改。

PG11.0及以后的版本支持通过参数"wal_segment_size"动态调整、数据库启动初始化时生效。另外也可以通过initdb配置选项"--with-wal-segsize"来修改配置。

2)archive_timeout 时间控制自动归档:

在 postgresql.conf 配置文件中的 archive_timeout 参数控制,如果设置 archive_timeout = 180s,则WAL日志会每 180s 切换一次WAL日志、并同时触发日志归档。

archive_timeout 的默认值是0、即未开启。

注意:不推荐设置 archive_timeout ,如果要设置,那也尽量不要把 archive_timeout 参数设置过小,如果太小会导致你配置的归档存储空间开销膨胀。因为,达到归档时间强制归档的日志,即使WAL日志文件没有写满,也会是默认的16MB(假设 wal_segment_size = 16MB 默认值)。

PostgreSQL中的oid和relfilenode:

PostgreSQL 创建一个普通表(外表和分区表除外)以后,pg_class 中存储它的 relfilenode 值,磁盘上也会创建一个对应的文件(),文件名和表的 relfilenode 值相同,表创建后,oid 和 relfilenode 相同。

查询数据库testdb01的oid:

testdb01=> select oid,datname from pg_database where datname='testdb01';

oid | datname

-------+----------

16437 | testdb01

(1 row)

查询表test01的oid:

testdb01=> select oid,relname,reltype,relfilenode from pg_class where relname like '%test%';

oid | relname | reltype | relfilenode

-------+----------------------------------+---------+-------------

27186 | test05 | 27188 | 27202

27192 | test05_pkey | 0 | 27204

27218 | test01 | 27220 | 27218

27221 | test01_pk | 0 | 27221

(11 rows)

查看库表对应的物理磁盘文件:

testdb01=> quit;

-bash-4.2$

-bash-4.2$ ls -l $PGDATA/base/16437/27218

-rw-------. 1 postgres postgres 8192 Feb 17 10:55 /var/lib/pgsql/12/data/base/16437/27218

-bash-4.2$

你可能感兴趣的:(数据库,postgresql,linux,数据库)