PostgreSQL WAL 文件中时间线与如何进行标识
PostgreSQL WAL 文件中时间线与如何进行标识
开头还是介绍一下群，如果感兴趣PolarDB ,MongoDB ,MySQL ,PostgreSQL ,Redis, Oceanbase, Sql Server等有问题，有需求都可以加群群内有各大数据库行业大咖，CTO，可以解决你的问题。加群请联系 liuaustin3 ，（共2150人左右 1 + 2 + 3 + 4 +5） 新人奖直接分配到5群,另欢迎 OpenGauss 的技术人员加入。
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: 0
postgres@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 文件，通过确定是否是一个时间线来进行数据的恢复。
本文分享自 AustinDatabases 微信公众号，前往查看
如有侵权，请联系 cloudcommunity@tencent.com 删除。
本文参与 腾讯云自媒体分享计划 ，欢迎热爱写作的你一起参与！