PostgreSQL内核学习--Chapter 10 Base Backup & Point-in-Time Recovery

Chapter 10 Base Backup & Point-in-Time Recovery（基础备份 & 时间点恢复）

• Online database backup can be roughly classified into two categories: logical and physical backups. While both of them have advantages and disadvantages, there is one disadvantage in logical backup; taking too much time for its performance.（在线数据库备份可以被粗略地分为两类：逻辑备份和物理备份；这两种备份各有优缺点，其中逻辑备份的缺点之一就是：执行时间这一项性能太差） In particular, it requires a fairy long time to make the backup of a large database, and even more time to restore such a database from backup data.（尤其是它要花大量的时间在大型数据库的辈备份上，甚至花费更多时间从备份数据中恢复数据库） On the contrary, physical backup makes it possible to backup and to restore large databases in a relatively short time so that it is a very important and useful feature in practical systems.（相反，物理备份就使得在一个相对更短的时间内备份和恢复大型数据库成为可能，因此它在实际系统中起非常重要和实用的作用）

• In PostgreSQL, online physical full backup has been available since version 8.0, and a snapshot of a running whole database cluster (i.e. physical backup data) is known as a base backup.（PG8.0版本开始就支持在线的全量物理备份这一功能了，整个数据簇（物理备份数据）的运行时快照被称之为基础备份）

• Point-in-Time Recovery (PITR), which has also been available since version 8.0, is the feature to restore a database cluster to any point in time using a base backup and archive logs created by continuous archiving feature.（时间点恢复这一功能也是PG8.0版本开始支持的，这个功能支持任意时间点利用基础备份和持续归档创建的归档日志恢复数据簇） For example, even if you made a critical mistake (e.g. truncating all tables), this feature enables you to restore the database of the point just before the mistake you have made.（例如，即使你犯了一个严重的错误（例如：截断了所有的表），这项功能可以将数据库恢复到犯错之前的时间点）

• In this chapter, following topics are described:（在这一章，将会介绍以下内容：）

  • What base backup is（基础备份是什么）

  • How PITR works（时间点恢复怎么执行）

  • What timelineId is（时间线标识是什么）

  • What timeline history file is（时间线标识历史文件是什么）

• 上一章XLOG记录和WAL分割文件中存储的是对数据库数据的修改操作，存储的是操作行为，而不是数据本身，这一章中的备份文件存储的数据库本身和其中的数据。

• 上一章主要恢复的是缓存和固存中数据不一致的这种意外，但如果固存中的数据也发生了意外导致错误或者丢失，就不能通过WAL来Recovery恢复了，需要用到备份Backup中的数据库数据来进行Recovery恢复

10.1. Base Backup（基础备份）

• First of all, the standard procedure to make a base backup using the low-level commands is shown below:（首先，用底层命令生成一个基础备份的标准步骤如下：）

  • (1) Issue the pg_backup_start command (Version 14 or earlier, pg_start_backup)（发出pg_backup_start命令）

  • (2) Take a snapshot of the database cluster with the archiving command you want to use（用你想用的归档命令生成一个数据簇的快照））

  • (3) Issue the pg_backup_stop command (Version 14 or earlier, pg_stop_backup)（发出pg_backup_stop命令）

• This simple procedure is easy-to-use for database system administrators, because it requires no special tools but common tools such as copy command or a similar archiving tools to create a base backup.（以上的简化步骤对于数据库系统的管理人员使用这项功能是很简单，因为它不需要任何特殊工具，但是需要一些常用的工具，例如，用于创建基础备份的拷贝命令or相似的归档工具） In addition, in this procedure, no table locks are required and all users can issue queries without being affected by backup operation. Those are big advantages over other major open source RDBMS.（此外，在以上步骤中，不需要对表上锁，所有用户都可以在不受其他备份操作的影响下发出请求，这是和其他开源关系数据库管理系统相比一个很大的优点）（说功能就说功能，搞什么拉踩，无语）

• More simple way to make a base backup is to use the pg_basebackup utility, but it internally issues those low-level commands.（生成一个基础备份更简单的方法是，用pg_basebackup实用程序，但其实它内部也是用通过发出底层命令来生成基础备份）

Fig. 10.1. Making a base backup.

• As the pair of those commands is clearly one of the key points for understanding the PITR, we will explore them in the following subsections.（上述这一对命令（指pg_backup_start和pg_backup_stop）是理解PITR时间点恢复这一功能的重点，我们将会在下面的子章节里探索这两个命令）
• 这两个命令定义在src/backend/access/transam/xlogfuncs.c

10.1.1. pg_backup_start (Ver.14 or earlier, pg_start_backup)

• The pg_backup_start prepares for making a base backup. As discussed in Section 9.8, recovery process starts from a REDO point, so the pg_backup_start must do checkpoint to explicitly create a REDO point at the start of making a base backup. Moreover, the checkpoint location of its checkpoint must be saved in a file other than pg_control because regular checkpoint might be done a number of times during backup. Hence the pg_backup_start performs the following four operations:（pg_backup_start准备生成一个基础备份，如9.8小节中讨论到的，恢复程序从REDO点开始，所以pg_backup_start必须启动生成基础备份的时候执行一次checkpoint以显式地创建一个REDO点，此外，这个checkpoint的checkpoint的位置必须与pg_control分属不同文件，因为备份期间可能会执行多次常规的checkpoint，因此pg_bcakup_start会执行如下操作：）
  1. Force into the full-page wirte mode.（强制进入整页写入模式）
  2. Switch to the current WAL segment file (version 8.4 or later).（切换成当前WAL分割文件）
  3. Do checkpoint.（执行一次checkpoint）
  4. Create a backup_label file – This file, created in the top level of the base directory, contains essential information about base backup itself, such as the checkpoint location of this checkpoint.（创建一个 备份标签文件，这个文件创建的位置在基础目录的顶层，包含关于基础备份自身相关的重要的信息，比如这次checkpoint的checkpoint位置）
• The third and fourth operations are the heart of this command; the first and second operations are performed to recover a database cluster more reliably.（第三和第四个操作时这条命令的重心，第一个和第二个操作执行用于更可靠地恢复数据簇）
• A backup_label file contains the following six items (version 11 or later, seven items):（一个 备份标签文件 包含以下六项条目，PG版本11以及之后有七项条目）
  • CHECKPOINT LOCATION – This is the LSN location where the checkpoint created by this command has been recorded.（CHECKPOINT LOCATION，Checkpoint位置，指记录执行这一次Checkpoint的XLOG的LSN值）
  • START WAL LOCATION – This is not used with PITR, but used with the streaming replication, which is described in Chapter 11. It is named ‘START WAL LOCATION’ because standby server in replication-mode reads this value only once at initial startup.（START WAL LOCATION，WAL开始的位置，这个条目没有被直接用于时间点恢复，而是用于流复制，也就是下一章会讲的东西，之所以叫START WAL LOCATION是因为复制模式下备用的服务只在初始化启动阶段读取一次这个值）
  • BACKUP METHOD – This is the method used to make this base backup. (Either ‘pg_backup_start’ or ‘pg_basebackup’.)（BACKUP METHOD，备份方法，这是一个用于生成基础备份的方法（既不是pg_backup_strat也不是pg_basebackup）
  • BACKUP FROM – This shows whether this backup is taken from primary or standby.（BACKUP FROM，备份来自与，这个条目指备份的数据是来自于最初的数据簇中的数据还是其他备份的数据）
  • START TIME – This is the timestamp when the pg_backup_start has executed.（START TIME，开始时间，这个条目是pg_backup_start执行的时间戳）
  • LABEL – This is the label specified at the pg_backup_start.（LABEL，标签，这个是pg_backup_start指定的标签）
  • START TIMELINE – This is the timeline that the backup started. This is for a sanity check and has been introduced in Version 11.（START TIMELINE，开始的时间线，这个条目是开始备份的时间线，用于健全性检查，将在第11章中介绍）
• An actual example of backup_label file in version 9.6 is shown in the following:（一个PG9.6版本中的备份标签文件的实例如下：）（这个文件，指backup_label，只有当执行pg_start_backup实用程序的过程在才会生成，例如执行SELECT pg_start_backup('backup02',false,true);时，在另一个会话中查看/pgdata/15.3/poc/data/目录，就会出现这个文件）

postgres> cat /usr/local/pgsql/data/backup_label
START WAL LOCATION: 0/9000028 (file 000000010000000000000009)
CHECKPOINT LOCATION: 0/9000060
BACKUP METHOD: pg_start_backup
BACKUP FROM: master
START TIME: 2023-8-4 11:45:19 GMT
LABEL: Weekly Backup

• As you may imagine, when you recover a database using this base backup, PostgreSQL takes the ‘CHECKPOINT LOCATION’ out of the backup_label file to read the checkpoint record from the appropriate archive log, and then, gets the REDO point from its record and starts recovery process. (The details will be described in the next section.)（正如你所想，当你用这个基础备份恢复一个数据库时，PG会从 备份标签文件 中取出CHECKPOINT LOCATION，然后找到该位置记录了这次checkpoint的XLOG记录读取checkpoint相关的记录，并开始恢复程序（这个细节将会在下一部分详细介绍））

10.1.2. pg_backup_stop (Ver.14 or earlier, pg_stop_backup)

• The pg_backup_stop performs the following five operations to complete the backup.（pg_backup_stop会执行以下五个操作以完成备份）
  1. Reset to non-full-page writes mode if it has been forcibly changed by the pg_backup_start.（如果要靠pg_backup_start的强力修改重新设定回到non_full_page也就是非整页写入的模式）
  2. Write a XLOG record of backup end.（写一个备份结束的XLOG记录）
  3. Switch the WAL segment file.（切换WAL分割文件）
  4. Create a backup history file – This file contains the contents of the backup_label file and the timestamp that the pg_backup_stop has been executed.（创建一个备份历史文件，这个文件应当包含 备份标签文件 的内容和pg_backup_stop执行完成的时间戳）
  5. Delete the backup_label file – The backup_label file is required for recovery from the base backup and once copied, it is not necessary in the original database cluster.（删除 备份标签文件，备份标签文件仅仅是从基础备份中恢复数据库所必须的，一旦被拷贝，原始数据簇中就不再需要这个文件了
• The naming method for backup history file is shown below.（备份历史文件 的命名方法如下所示;）

{WAL segment}.{offset value at the time the base backup was started}.backup

10.2. How Point-in-Time Recovery Works（PITR时间点恢复模式是怎样工作的）

• Figure 10.2 shows the basic concept of PITR. PostgreSQL in PITR-mode replays the WAL data of the archive logs on the base backup, from the REDO point created by the pg_backup_start up to the point you want to recover. In PostgreSQL, the point to be recovered is referred to as a recovery target.（下图展示了PITR时间点恢复的基本概念，PG在PITR时间点恢复的模式下会重现基础备份中已经归档的WAL事务日志中的XLOG数据，从pg_backup_start创建的REDO点开始到你想要恢复的点（也就是恢复目标）处结束；PG中，要恢复到那个位置才暂停恢复的位置被称之为recovery target（恢复目标）。

Fig. 10.2. Basic concept of PITR.（PITR一句话解释：就是利用REDO点存储的基础备份文件和归档日志中的WAL数据，也就是发生错误前某一个时间点（REDO点）存储的数据库数据，重新复现一遍从那一点开始所有对数据库执行的修改操作，直到发生错误前一刻，这样获得的数据库和发生错误前的数据库就是一模一样的了，这个就被称之为修复后的数据库）

• Here is the description of how PITR works. Suppose that you made a mistake at 12:05 GMT of 7 August, 2023. You should remove the database cluster and restore the new one using the base backup you made before that.（这里是PITR怎样工作的示例；假设在上述时间点犯下了一个错误，你应该移除数据簇并用基础备份重新存储一个新的之前的版本的数据簇）Then, set the command of the parameter restore_command, and also set the time of the parameter recovery_target_time at the point you made the mistake (in this case, 12:05 GMT) in a recovery.conf (version 11 or earlier) or postgresql.conf (version 12 or later).（在配置文件postgresql.conf文件中设置参数restore_command 的命令，同时设置recovery_target_time的时间为错误操作的时间（在本例中这个值为12:05 GMT）

# Place archive logs under /mnt/server/archivedir directory.
restore_command = 'cp /mnt/server/archivedir/%f %p'
recovery_target_time = "2023-8-7 12:05 GMT"

• When PostgreSQL starts up, it enters into PITR mode if there are a recovery.conf (version 11 or earlier) or recovery.signal(version 12 or later), and a backup_label in the database cluster.（当PG启动时，如果存在recovery.singal文件和backup_lable备份标签文件，他会进入PITR时间点恢复模式）
• If a recovery target is not set to the recovery.conf (version 11 or earlier) or the postgresql.conf (version 12 or later), PostgreSQL will replay until the end of archiving logs.（如果恢复目标没有被设置到postgresql.conf，PG就会重现归档中的WAL中的XLOG语句直到档案日志的结尾）
• PITR process is almost the same as the normal recovery process described in Chapter 9; the only differences between them are the following two points:（PITR程序几乎和第九章描述的平常的恢复程序差不多一样
  1. Where are WAL segments/Archive logs read from?（在哪里读取WAL分割文件 / 归档日志文件？）
     • Normal recovery mode – from the pg_xlog subdirectory (in version 10 or later, pg_wal subdirectory) under the base directory.（正常恢复模式（也就是上一章节中的）—— 从基础目录下的pg_wal子目录下读取WAL分割文件）
     • PITR mode – from an archival directory set in the configuration parameter archive_command.（PITR时间点恢复模式——从配置文件的参数archive_command设置的归档目录下读取归档日志文件）
  2. Where is the checkpoint location read from?（从哪里读取checkpoint》）
     • Normal recovery mode – from a pg_control file.（正常恢复模式——从pg_control文件中读取checkpoint）
     • PITR mode – from a backup_label file.（PITR时间点恢复模式——从 基础备份 文件，也就是backup_lable文件中读取checkpoint）
• The outline of PITR process is described as follows:（PITR时间点恢复程序的流程概述如下：）
  • (1) In order to find the REDO point, PostgreSQL reads the value of ‘CHECKPOINT LOCATION’ from the backup_label file with the internal function read_backup_label.（为了找到REDO点，PG利用内部函数read_backup_lable()从 备份标签文件 中读取checkpoint的位置）
  • (2) PostgreSQL reads some values of parameters from the recovery.conf (version 11 or earlier) or the postgresql.conf (version 12 or later) ; in this example, restore_command and recovery_target_time.（PG会从postgresql.conf中读取一些参数的值，在本例中，读取了restore_command和recovery_target_time 这两个参数的值）
  • (3) PostgreSQL starts replaying WAL data from the REDO point, which can be easily obtained from the value of ‘CHECKPOINT LOCATION’. The WAL data are read from archive logs which are copied from the archival area to a temporary area by executing the command written in the parameter resotere_command.（PG开始从REDO点恢复WAL数据，可以从checkpoint位置值处很轻松地获得REDO点；WAL数据是从归档日志中读取的，通过执行参数resoter_command中写入的命令，将归档日志从归档区域复制到临时区域） (The copied log files in the temporary area are removed after using.)
  • In this example, PostgreSQL reads and replays WAL data from the REDO point to the one before the timestamp ‘2023-8-7 12:05:00’ because the parameter recovery_target_time is set to this timestamp. If a recovery target is not set to the recovery.conf (version 11 or earlier) or the postgresql.conf (version 12 or later), PostgreSQL will replay until the end of archiving logs.（在这个例子中，PG从后往前读取和恢复，从REDO点到时间戳2023-8-7 12:05:00的数据，因为参数recovery_target_time被设置为了这刚时间戳，如果一个恢复目标没被设置到postgresql.conf，PG将会一直重现下去，直到此归档日志结束的地方）
  • (4) When the recovery process completes, a timeline history file, such as ‘00000002.history’, is created in the pg_xlog subdirectory (in version 10 or later, pg_wal subdirectory); if archiving log feature is enabled, same named file is also created in the archival directory. The contents and role of this file are described in the following sections.（当恢复程序完成时，在pg_wal子目录下面会自动创建一个时间线历史文件，命名就像00000002.history，如果归档日志功能处于启动状态，也会自动创建一个相同名字的文件在归档目录下；这个文件的内容和作用在下面部分介绍：）
• The records of commit and abort actions contain the timestamp at which each action has done (XLOG data portion of both actions are defined in [xl_xact_commit](javascript:void(0)) and [xl_xact_abort](javascript:void(0)) respectively). Therefore, if a target time is set to the parameter recovery_target_time, PostgreSQL may select whether to continue recovery or not, whenever it replays XLOG record of either commit or abort action. When XLOG record of each action is replayed, PostgreSQL compares the target time and each timestamp written in the record; and if the timestamp exceed the target time, PITR process will be finished.（提交和终止操作的记录包含了这个操作完成时的时间戳；因此，如果目标时间被设置为参数recovery_target_time，又正好碰上PG提交or终止操作时重现XLOG记录，PG可能会选择是否继续恢复；当每一个操作的XLOG记录都被重现，PG会将比较目标时间和XLOG记录中的每一个时间戳进行比较，如果时间戳超过了目标时间（也就是恢复到了目标时间之前的一个时间点了已经），PITR时间点恢复程序就会结束）

10.3. TimelineId and Timeline History File（时间线标识和时间线历史文件）

• Timeline in PostgreSQL is used to distinguish between the original database cluster and the recovered ones, and is central concept of PITR. In this section, two things associated with the timeline are described: timelineId and timeline history files.（PG timeline时间线用于区分原始数据簇和已经恢复过的，并且时间线是PITR中一个关键的概念，这一部分里，将会介绍两个和timeline时间线有关的概念：timelineId，时间线标识 和 timeline history files，时间线历史文件）

10.3.1. timelineId（时间线标识）

• Each timeline is given a corresponding timelineId, a 4-byte unsigned integer starting at 1.（每一个时间线都会被分配一个对应的timelineId，时间线标识，它是一个4个字节的无符号整型数，从1开始计数）
• An individual timelineId is assigned to each database cluster. The timelineId of original database cluster created by the initdb utility is 1. Whenever database cluster recovers, timelineId will be increased by 1. For example, in the example of the previous section, the timelineId of the cluster recovered from the original one is 2.（每一个数据簇都会有一个自己的timelineId时间线标识；刚初始化的数据库的时间线标识timelineId是由initdb这个程序创建，均为1。例如，在上一个小节的例子中，数据簇在没有恢复之前timelineId=1，恢复后的timelineId时间线标识从1变成了2）
• Figure 10.3 illustrates the PITR process from the viewpoint of the timelineId. First, we remove our current database cluster and restore the base backup made in the past, in order to go back to the starting point of recovery, and such situation is represented in the red arrow curve in the figure.（下图10.3展示了从时间线的PITR程序，首先，我们删除了当前的数据库集群，并恢复了过去的基本备份，以便回到恢复的起点，这种情况如图中的红色箭头曲线所示：） Next, we start the PostgreSQL server which replays WAL data in the archive logs from the REDO point created by the pg_backup_start until the recovery target by tracing along the initial timeline (timelineId 1), and such situation is represented in the blue arrow line in the figure.（接下来，我们启动PG服务，沿着初始化数据库的timeline时间线（timelineId=1），用pg_backup_start从REDO点开始到恢复目标点结束，重现归档日志中的WAL数据；这个产经在下图10.3中用蓝色的箭头表示出来了） Then, a new timelineId 2 is assigned to recovered database cluster and PostgreSQL runs on the new timeline.（然后PG将会分配一条timelineId=2的新timeling时间线给已经被恢复的数据簇，PG也会运行这条新的时间线timelineId）

Fig. 10.3. Relation of timelineId between an original and a recovered database clusters.

• As briefly mentioned in Chapter 9, the first 8-digit of WAL segment filename is equal to the timelineId of the database cluster created for each segment. When the timelineId is changed, WAL segment filename will also be changed.（第九章中简短地提到过，WAL分割文件名字中的前八个数字是数据簇的timelineId时间线标识，当时间线标识被修改之后，WAL分割文件的名字也会发生变化）
• Focusing on WAL segment files, the recovery process will be described again. Suppose that we recover the database cluster using two archive logs ‘000000010000000000000009’ and ‘00000001000000000000000A’. The newly recovered database cluster is assigned the timelineId 2, and PostgreSQL creates the WAL segment from ‘00000002000000000000000A’. Figure 10.4 shows this situation.（以WAL分割文件为重点，恢复程序将会再次被介绍：假设我们用两个文档日志恢复了数据簇000000010000000000000009 和00000001000000000000000A‘新的被恢复后的数据簇被分配到的时间线标识是timelineId=2，并且PG以新的名字创建WAL分割文件的名字）

Fig. 10.4. Relation of WAL segment files between an original and a recovered database clusters.

10.3.2. Timeline History File（时间线历史文件）

• When a PITR process completes, a timeline history file with names like ‘00000002.history’ is created under the archival directory and the pg_xlog subdirectory (in version 10 or later, pg_wal subdirectory). This file records which timeline it branched off from and when.（当一个PITR时间点恢复程序完成时，以00000002.history命名的timeline时间线历史文件就会在归档目录和pg_wal\目录下被创建，这个文件记录了时间线是从哪个时间线分支出来的以及何时分支出来的）
• The naming rule of this file is shown in the following:（这个文件的命名规则如下：）

"8-digit new timelineId".history

• A timeline history file contains at least one line, and each line is composed of the following three items:（一个时间线历史文件包含了至少一个时间线，每一条时间线是由以下三项条目组成的：）
  • timelineId – timelineId of the archive logs used to recover.（timelineId时间线标识——用于恢复的归档日志的时间线标识）
  • LSN – LSN location where the WAL segment switches happened.（LSN (Log Sequence Number)，日志序列号，也就是XLOG的标识符和位置所在，WAL分割文件切换发生的LSN位置
  • reason – human-readable explanation of why the timeline was changed.（reason原因：用人类语言解释为什么时间线被改变了）
• A specific example is shown below:（timeline history file时间线历史文件举例如下：）

postgres> cat /home/postgres/archivelogs/00000002.history
1	  0/A000198	before 2023-8-8 12:05:00.861324+00

• Meaning as follows:（意思如下：

  The database cluster (timelineId=2) is based on the base backup whose timelineId is 1, and is recovered in the time just before ‘2023-8-8 12:05:00.861324+00’ by replaying the archive logs until the 0/A000198.（当前timelineId=2的数据簇是基于timelineId=1的基础备份，并且它在这个时间点被恢复，由归档日志截止到LSN=0/A000198的XLOG记录

• In this way, each timeline history file tells us a complete history of the individual recovered database cluster. Moreover, it is also used to PITR process itself. The detail is explained in the next section.（这种情况下，每一个时间线历史文件就能告诉我们单个被恢复的数据簇的一套完整历史，此外，它还用于PITR时间点恢复程序自身，下一部分将具体介绍时间线历史文件如何在时间点恢复模式中的运用）

10.4. Point-in-Time Recovery with Timeline History File（使用时间线历史文件下的PITR时间点恢复模式）

• The timeline history file plays an important role in the second and subsequent PITR processes. By trying the second time recovery, we will explore how it is used.（时间线历史文件在第二个和后续的PITR程序中承担了重要的作用（第一次使用PITR进行数据簇恢复时还没有生成任何的时间线历史文件，所以是从第二次PITR开始才有），通过尝试推演第二次的恢复过程，我们将探索它（指时间线历史文件）是怎样被运用的）
• Again, suppose that you made a mistake at 12:15:00 in the recovered database cluster whose timelineId is 2. In this case, to recover the database cluster, you should create a new recovery.conf shown below:（再次，假设在12:15在已经被恢复过一次的timelineId=2的数据簇上犯下了一个错误，这种情况下，再次恢复数据簇，你应该重新设置postgresql.conf文件中的两个参数（如10.2小节中所述的restore_command和recovery_traget_time）

restore_command = 'cp /mnt/server/archivedir/%f %p'
recovery_target_time = "2023-8-8 12:15:00 GMT"
recovery_target_timeline = 2

• The parameter recovery_target_time sets the time you made new mistake, and the recovery_target_timeline is set at ‘2’, in order to recover along its timeline.（参数recovery_target_time设置为第二次犯错操作的时间，recovery_target_timeline设置为2，也就是指明这一次恢复数据簇是根据哪条时间线来进行恢复）
• Restart the PostgreSQL server and enter PITR mode to recover the database at the target time along the timelineId 2. See Fig. 10.5.（如下图10.5，重启PG服务器，并进入PITR模式下，对数据库沿着timelineId=2的时间线进行恢复）

Fig. 10.5. Recover the database at 12:15:00 along the timelineId 2.

• (1) PostgreSQL reads the value of ‘CHECKPOINT LOCATION’ from the backup_label file.（PG从 备份标签文件 中读取checkpoint location检查点位置的值）
• (2) Some values of parameters are read from the recovery.conf; in this example, restore_command, recovery_target_time, and recovery_target_timeline.（从postgresql.conf中读取一些参数的值，在本例中，包括这三个参数的值restore_command、recovery_traget_time和recovery_target_timeline）
• (3) PostgreSQL reads the timeline history file ‘00000002.history’ which is corresponding to the value of the parameter recovery_target_timeline.（PG读取时间线历史文件00000002.history，文件名的timelineId与上述中参数recovery_target_timeline值一致的那个时间线历史文件）
• (4) PostgreSQL does replaying WAL data by the following steps:（PG按照以下步骤执行WAL数据的重现：）
  • \1. From the REDO point to the LSN ‘0/A000198’ which is written in the 00000002.history file, PostgreSQL reads and replays WAL data of appropriate archive logs whose timelineId is 1.（从写在00000002.history文件里的REDO点开始到LSN=0/A000198的那一条XLOG记录截止，PG读取并重现timelineId=1的适当归档日志中的WAL数据）
  • \2. From the one after LSN ‘0/A000198’ to the one before the timestamp ‘2023-8-8 12:15:00’, PostgreSQL reads and replays WAL data (of appropriate archive logs) whose timelineId is 2.（从LSN=0/A000198的下一条XLOG记录到时间戳为犯下第二次错误的时间前的这一条XLOG记录达止，PG读取和重现timelineId=2的适当归档日志中的这其中的所有XLOG记录）
• (5) When the recovery process completes, the current timelineId will advance to 3, and new timeline history file named 00000003.history is created in the pg_xlog subdirectory (pg_wal subdirectory if version 10 or later) and the archival directory.（当恢复程序完成，当前的timelineId会前进到3，新的时间线历史文件将会被命名为00000003.history被存储在pg_wal/目录和归档日志的目录下面）

postgres> cat /home/postgres/archivelogs/00000003.history
1         0/A000198     before 2023-8-8 12:05:00.861324+00

2         0/B000078     before 2023-8-8 12:15:00.927133+00

• When you do PITR more than once, you should explicitly set a timelineId for using the appropriate timeline history file.（当你执行更多次PITR时，你应该显式地设置timelineId，以便更恰当地使用时间线历史文件）
• In this way, timeline history files are not only history logs of database cluster, but also the recovery instruction documents for PITR process.（在这种方式下，时间线历史文件不仅仅是数据簇的历史日志，同样也是PITR程序的恢复程序的说明书文件）