PostgreSQL WAL 文件中时间线与如何进行标识
source link: https://blog.51cto.com/u_14150796/10681267
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
PostgreSQL WAL 文件中时间线与如何进行标识
精选 原创
PostgreSQL 中可以通过时间线的概念在日志中标记数据库中操作的一切。通过调用pg_controldata，查看当前的数据库的wal日志正在使用的是哪个，这里的是 000000010000000000000012 。但注意看下面两个部分，非常短的时间，WAL日志有了变化，这里我做了一个操作，恢复数据库。今天的讨论就从恢复数据库后的 history 文件开始。
root@pg16:~# su - postgres
postgres@pg16:~$ pg_controldata
pg_control version number: 1300
Catalog version number: 202307071
Database system identifier: 7309003792944632868
Database cluster state: in production
pg_control last modified: Wed 06 Mar 2024 08:59:38 AM UTC
Latest checkpoint location: 0/120000C0
Latest checkpoint's REDO location: 0/12000088
Latest checkpoint's REDO WAL file: 000000010000000000000012
Latest checkpoint's TimeLineID: 1
Latest checkpoint's PrevTimeLineID: 1
Latest checkpoint's full_page_writes: on
Latest checkpoint's NextXID: 0:770
Latest checkpoint's NextOID: 16400
Latest checkpoint's NextMultiXactId: 1
Latest checkpoint's NextMultiOffset: 0postgres@pg16:/pgdata/data/pg_wal$ pg_controldata
pg_control version number: 1300
Catalog version number: 202307071
Database system identifier: 7309003792944632868
Database cluster state: in production
pg_control last modified: Wed 06 Mar 2024 09:05:38 AM UTC
Latest checkpoint location: 0/15000028
Latest checkpoint's REDO location: 0/15000028
Latest checkpoint's REDO WAL file: 000000020000000000000015
Latest checkpoint's TimeLineID: 2
Latest checkpoint's PrevTimeLineID: 1
Latest checkpoint's full_page_writes: on
Latest checkpoint's NextXID: 0:771
Latest checkpoint's NextOID: 16400
Latest checkpoint's NextMultiXactId: 1
Latest checkpoint's NextMultiOffset: 0
Latest checkpoint's oldestXID: 722
Latest checkpoint's oldestXID's DB: 1
Latest checkpoint's oldestActiveXID: 0
Latest checkpoint's oldestMultiXid: 1
Latest checkpoint's oldestMulti's DB: 1
postgres@pg16:/pgdata/data/pg_wal$ cat 00000002.history
1 0/15000000 no recovery target specified
postgres@pg16:/pgdata/data/pg_wal$
postgres@pg16:/pgdata/data/pg_wal$在history文件里面存储这一些文字内容，而这些文字的内容到底是干什么的，我们为了去获得更多的内容，
postgres@pg16:/pgdata/data$ cd pg_wal/
postgres@pg16:/pgdata/data/pg_wal$ ls
000000030000000000000015 000000030000000000000017 archive_status
000000030000000000000016 00000003.history
postgres@pg16:/pgdata/data/pg_wal$
postgres@pg16:/pgdata/data/pg_wal$
postgres@pg16:/pgdata/data/pg_wal$ cat 00000003.history
1 0/15000000 no recovery target specified
postgres@pg16:/pgdata/data/pg_wal$在操作完毕，里面的内容没有变，但是编号变了。变成了0000003.history
postgres@pg16:/pgdata/data$ cd pg_wal/
postgres@pg16:/pgdata/data/pg_wal$ ls
00000003.history 000000040000000000000019 00000004.history
000000040000000000000018 00000004000000000000001A archive_status
postgres@pg16:/pgdata/data/pg_wal$ cat 00000004.history
1 0/15000000 no recovery target specified
3 0/18000000 no recovery target specified
postgres@pg16:/pgdata/data/pg_wal$ ls
00000003.history 000000040000000000000019 00000004.history
000000040000000000000018 00000004000000000000001A archive_status
postgres@pg16:/pgdata/data/pg_wal$当我这次备份数据库，后在进行恢复，给我的信息和之前又不一样，那么问题来了，为什么每次在数据库恢复后，都会多一个history文件，他的功能是什么，同时为什么每次恢复一次数据库，其中的0000000？会有变化每次恢复后都会加1 ，这些问题都是怎么回事。
实际上在上面提出的第一个问题，这个位置的数字相当于WAL中的分歧点，代表一个数据库恢复后的WAL开始的LSN的分歧。
例如：pg_wal/000000010000000000000001，表示这个 WAL 段属于时间线 ID = 1以及pg_wal/000000020000000000000001，表示这个 WAL 段属于时间线 ID = 2
上马的例子就说明这个数据库恢复过一次，所以从1变成2了. 他这里有点像git的分支，但是不能合并的那种，
那么为什么会这样，我们可以理解为数据库最早的时间线是ID 1 ，后面所有的数据都是在时间线1 上进行的当我们备份数据库后在数据库上进行恢复后，则创建了时间线2 ，此后的操作都是属于时间线2的，每次进行备份后恢复都会创建新的时间线。
那么当恢复数据库的时候，会在数据库中的pg_wal 中建立一个新.history 的文件，该文件描述了回放数据库中的分歧点，如果没有这个文件就无法确定数据恢复的时间线的来源，也就无法确定PITR的恢复的相关需要的信息。通过这样的概念，如果有相同的LSN号，或相同的WAL存在多个时间线中，在数据恢复中会根据当前的时间轴来进行数据的恢复。
这点在PG中非常重要尤其适用通过archive 来对WAL日志进行归档的情况下，归档文件中可能会存在多个时间线的wal 文件，通过确定是否是一个时间线来进行数据的恢复。
Recommend
About Joyk
Aggregate valuable and interesting links.
Joyk means Joy of geeK