墨墨导读：最近电子工业出版社博文视点出版了《PostgreSQL指南：内幕探索》，日前「数据和云」公众号推荐了这本书并赠送了五本，百多位用户参与，几十条留言未能放出，为了让大家更好地学习开源数据PostgreSQL，经出版社官方授权，刊载本书部分章节内容以飨读者，本文节选了第十章《基本备份与时间点恢复》10.3-10.4。
此外，我们也成立PostgreSQL学习社群，技术探讨、资料分享、大牛解答，欢迎加入一起进步，入群方式见文末。
上期，我们分享了《PostgreSQL 指南：内幕探索》之基础备份与时间点恢复（上），本文为大家分享下半部分。
本文描述了以下主题：
基础备份
时间点恢复（PITR）的工作原理
时间线与时间线历史文件
时间点恢复与时间线历史文件
时间线与时间线历史文件
PostgreSQL中的时间线用于区分原始数据库集簇和恢复生成的数据库集簇，它是PITR的核心概念。此文描述了与时间线相关的两件事，分别是时间线标识和时间线历史文件。
时间线标识
每个时间线都有一个相应的时间线标识，是一个4B的无符号整型数，从1开始计数。
每个数据库集簇都会被指定一个时间线标识。由initdb命令创建的原始数据库集簇，其时间线标识为1。每当数据库集簇恢复时，时间线标识都会增加1。例如上篇文章的例子中，从原始集簇中恢复得到的集簇，其时间线标识为2。
如下图所示，从时间线标识的角度展示了PITR过程。首先，我们删除当前的数据库集簇，并替换为过去的基础备份，以便返回到恢复的起始点，这一步在图中用上侧的曲线箭头标识。接下来，我们启动PostgreSQL服务器，它通过跟踪初始时间线（时间线标识1），从pg_start_backup创建的重做点开始，重放归档日志中的WAL数据，直到恢复目标达成，这一步在图中用浅色直线箭头标识。最后，恢复得到的数据库集簇将被分配一个新的时间线标识2，而PostgreSQL将运行在新的时间线上。
原始数据库集簇和恢复数据库集簇之间时间线标识的关系
WAL段文件名的前8位数字等于创建这些段文件的数据库集簇的时间线标识。当时间线标识发生变化时，WAL段文件名也会发生相应的改变。
让我们从WAL段文件的角度重新审视恢复过程。假设我们使用两个归档日志文件来恢复数据库，分别是000000010000000000000009和00000001000000000000000A。新恢复得到的数据库集簇被分配了时间线标识2，而PostgreSQL就会从00000002000000000000000A开始创建WAL段，如下图所示。
原始数据库集簇和恢复数据库集簇之间WAL段文件的关系
时间线历史文件
当PITR过程完成时，会在归档目录和pg_xlog子目录（在10.0或更高版本中为pg_wal子目录）下创建名称为00000002.history的时间线历史文件。该文件记录了当前时间线是从哪条时间线分叉出来的，以及分叉的时间。
该文件的命名规则如下所示：
“8位数字的新时间线标识”.history时间线历史文件至少包含一行，每行由以下3项组成：
时间线标识——曾用于恢复的归档日志的时间线。
LSN——发生WAL段切换的LSN位置。
原因——可读的时间线发生变化的原因解释。
具体示例如下所示：
postgres> cat /home/postgres/archivelogs/00000002.history
1 0/A000198 before 2018-7-912:05:00.861324+00含义如下：
数据库集簇（时间线标识为2）基于时间线标识为1的基础备份，并在2018-7-9 12:05:00.861324+00之前，通过重放检查点日志，恢复至0/A000198的位置。 |
通过这种方式，每个时间线历史文件都会告诉我们每个恢复所得的数据库集簇的完整历史，而且它在PITR过程中也有使用。第10.4节将描述具体细节。
时间线历史文件的格式在9.3版本中发生了变化。9.3前后的格式如下所示，但相对简略。 9.3及更高版本： 9.2及更低版本： |
时间点恢复与时间线历史文件
时间线历史文件在第二次及后续PITR过程中起着重要作用。通过尝试第二次恢复，我们将探索如何使用它。
同样，假设你在12:15:00时间点又犯了一个错误，错误发生在时间线ID为2的数据库集簇上。在这种情况下，为了恢复数据库集簇，你需要创建一个如下所示的recovery.conf文件：
restore_command ='cp /mnt/server/archivedir/%f %p'
recovery_target_time = "2018-7-16 12:15:00 GMT"
recovery_target_timeline = 2参数recovery_target_time被设置为犯下新错误的时间，而recovery_target_ timeline被设置为2，以便沿着这条时间线恢复。
重启PostgreSQL服务器并进入PITR模式，数据库会沿着时间线标识2进行恢复，如下图所示。
沿着时间线2将数据库恢复至12:15:00的状态
PostgreSQL从backup_label文件中读取CHECKPOINTLOCATION的值。
从recovery.conf中读取一些参数值，在此示例中为restore_command、recovery_target_time和recovery_target_timeline。
PostgreSQL读取时间线历史文件00000002.history，该文件对应参数recovery_target_timeline的值。
PostgreSQL通过以下步骤重放WAL数据：
（1）对于从重做点到LSN 0/A000198（该值写在00000002.history文件中）之间的WAL数据，PostgreSQL会（从合适的归档日志中）读取并重放TimelineID=1的WAL数据。
（2）对于从LSN 0/A000198到时间戳2018-7-9 12:15:00之间的WAL数据，PostgreSQL会（从合适的归档日志中）读取并重放TimelineID=2的WAL数据。
当恢复过程完成时，当前的时间线标识将增加到3，并在pg_xlog子目录（在10.0及更高版本中为pg_wal子目录）和归档目录中创建名为00000003.history的新时间线历史文件。
postgres> cat/home/postgres/archivelogs/00000003.history
1 0/A000198 before 2018-7-9 12:05:00.861324+00
2 0/B000078 before 2018-7-9 12:15:00.927133+00当你进行过超过一次的PITR时，应明确设置时间线标识，以便使用合适的时间线历史文件。
因此，时间线历史文件不仅是数据库集簇的历史日志，还是PITR过程的参考恢复指令。
墨墨导读：最近电子工业出版社博文视点出版了《PostgreSQL指南：内幕探索》，日前「数据和云」公众号推荐了这本书并赠送了五本，百多位用户参与，几十条留言未能放出，为了让大家更好地学习开源数据PostgreSQL，经出版社官方授权，刊载本书部分章节内容以飨读者，本文节选了第十章《基本备份与时间点恢复》10.1-10.2。
此外，我们也成立PostgreSQL学习社群，技术探讨、资料分享、大牛解答，欢迎加入一起进步，入群方式见文末。
在线数据库备份大致可分为逻辑备份和物理备份两类，它们各自都有优点和缺点。逻辑备份有一个缺点，即执行需要花费大量的时间。特别是对于大型数据库而言，需要花费很长时间进行备份，而从备份数据中恢复数据库可能需要更长的时间。相反，物理备份可以在相对较短的时间内备份和恢复大型数据库，因此在实际系统中，其是一个非常重要且实用的功能。
在PostgreSQL中，自8.0版本开始提供了在线的全量物理备份，整个数据库集簇（即物理备份数据）的运行时快照被称为基础备份。
PostgreSQL还在8.0版中引入了时间点恢复（Point-In-Time Recovery，PITR）。这一功能可以将数据库恢复至任意时间点，这通过使用一个基础备份和由持续归档生成的归档日志来实现。例如，即使你犯了一个严重的错误（如TRUNCATE所有的表），此功能还可以将数据库恢复至错误发生之前的时刻。
本文描述了以下主题：
基础备份
时间点恢复（PITR）的工作原理
时间线与时间线历史文件
时间点恢复与时间线历史文件
在7.4或更低版本中，PostgreSQL仅支持逻辑备份（全量逻辑备份、部分逻辑备份和数据导出）。
基础备份
制作基础备份
使用底层命令进行基本备份的标准过程上图所示，具体步骤如下：
发出pg_start_backup命令。
使用你想用的归档命令获取数据库集簇的快照。
发出pg_stop_backup命令。
这个简单的过程对于DBA来说很容易操作，因为它不需要特殊工具，只需要常用工具（如复制命令或类似的归档工具）来创建基本备份。此外，在此过程中，不需要获取表上的锁，所有用户都可以在不受备份操作影响的情况下发起查询。相对于其他开源的关系型数据库，这是一个巨大的优势。
更简单的方式是使用pg_basebackup命令来做基础备份，不过在其内部也是使用这些底层命令来工作的。
这些命令对显然是理解PITR的关键点之一，我们将在后续章节中探讨它们。
pg_start_backup和pg_stop_backup命令的定义在src/backend/access/transam/xlogfuncs.c中。 |
pg_start_backup
pg_start_backup开始为制作基础备份进行准备工作。恢复过程从重做点开始，因此pg_start_backup必须执行检查点，以便在制作基础备份的开始时刻显式创建一个重做点。此外，这次检查点的位置必须保存在非pg_control的其他文件中，因为在备份期间可能会执行多次常规检查点。
pg_start_backup执行下列4个操作：
强制进入整页写入模式。
切换到当前的WAL段文件（8.4或更高版本）。
执行检查点。
创建backup_label文件 —— 该文件创建于基本目录顶层中，包含有关该基本备份本身的关键信息，如检查点的检查点位置。
第3个和第4个操作是该命令的核心。第1和第2个操作是为了更可靠地恢复数据库集簇。
备份标签backup_label文件包含以下7个项目：
检查点位置 —— 该命令所创建检查点的LSN位置。
WAL开始位置——这不是给PITR用的，而是为第11章描述的流复制准备的。它被命名为START WAL LOCATION，因为复制模式下的备用服务器在初始启动时只读取一次该值。
备份方法——这是用于进行此基本备份的方法，如pg_start_backup或pg_basebackup。
备份来源 —— 说明此备份是从主库还是备库拉取。
开始时间 —— 这是执行pg_start_backup时的时间戳。
备份标签 —— 这是pg_start_backup中指定的标签。
开始时间线 —— 这是备份开始的时间线，为了进行正常的检查，在版本11.0中被引入。
备份标签 一个9.6版本中备份标签的实际例子如下所示： |
可以想象，当使用此基础备份恢复数据库时，PostgreSQL从backup_label文件中取出检查点位置CHECKPOINTLOCATION，接着从归档日志中的合适位置读取检查点记录，然后从检查点记录中获取重做点的位置，最后从重做点开始进行恢复。
pg_stop_backup
pg_stop_backup执行以下5个操作以完成备份：
如果pg_start_backup打开了整页写入，那么关闭整页写入。
写入一条备份结束的XLOG记录。
切换WAL段文件。
创建一个备份历史记录文件 —— 此文件包含backup_label文件的内容，以及已执行pg_stop_backup的时间戳。
删除backup_label文件 —— 从基础备份恢复需要backup_label文件，不过一旦被复制，原始的数据库集簇就不需要该文件了。
备份历史文件的命名方法如下所示： {WAL段文件名}.{基础备份开始时的偏移量}.backup |
时间点恢复（PITR）的工作原理
下图展示了PITR的基本概念。PITR模式下的PostgreSQL会在基础备份上重放归档日志中的WAL数据，从pg_start_backup创建的重做点开始，恢复到你想要的位置为止。在PostgreSQL中，想要恢复到的位置被称为恢复目标。
PITR的基本概念
PITR是如下这样工作的。假设你在GMT时间2018-07-1612:05:00犯了错误，那么就应该删掉当前的数据库集簇，并使用之前制作的基础备份恢复一个新的，然后创建一个recovery.conf文件，并在其中将recovery_target_time参数配置为犯错误的时间点，在本例中，也就是12:05 GMT。recovery.conf文件如下所示：
# Place archivelogs under /mnt/server/archivedir directory.restore_command = 'cp /mnt/server/archivedir/%f %p'recovery_target_time = "2018-7-16 12:05 GMT"在PostgreSQL启动的时候，如果数据库集簇中存在recovery.conf和backup_label文件，就会进入恢复模式。
PITR过程几乎与常规恢复过程一模一样，唯一的区别只有以下两点：
从哪里读取WAL段/归档日志？
正常恢复模式 —— 来自基础目录下的pg_xlog子目录（在10.0或更高版本中为pg_wal子目录）。
PITR模式 —— 来自配置参数archive_command中设置的归档目录。
从哪里读取检查点位置？
正常恢复模式 —— 来自pg_control文件。
PITR模式 —— 来自backup_label文件。
PITR流程概述如下：
为了找到重做点，PostgreSQL使用内部函数read_backup_label从backup_label文件中读取CHECKPOINTLOCATION的值。
PostgreSQL从recovery.conf中读取一些参数值，在此例中为restore_command和recovery_target_time。
PostgreSQL开始从重做点重放WAL数据，重做点的位置可以简单地从CHECKPOINT LOCATION的值中获得。PostgreSQL执行参数restore_command中配置的命令，将归档日志从归档区域复制到临时区域，并从中读取WAL数据，复制到临时区域中的日志文件会在使用后被删除。
在本例中，因为参数recovery_target_time被设置为该时间戳，所以PostgreSQL从重做点读取并重放WAL数据，直到时间戳2018-7-1612:05:00为止。如果recovery.conf中没有配置恢复目标，则PostgreSQL将重放至归档日志的末尾。
当恢复过程完成时，会在pg_xlog子目录（在10.0或更高版本中为pg_wal子目录）中创建时间线历史文件，如00000002.history。如果启用了日志归档功能，则还会在归档目录中创建相同的命名文件。接下来各节会介绍此文件的内容和作用。
提交和中止操作的记录包含每个操作完成时的时间戳（两个操作的XLOG数据部分分别在xl_xact_commit和xl_xact_abort中定义）。因此，如果将目标时间设置为参数recovery_target_time，只要PostgreSQL重放提交或中止操作的XLOG记录，就可以选择是否继续恢复。当重放每个动作的XLOG记录时，PostgreSQL会比较目标时间和记录中写入的每个时间戳，如果时间戳超过目标时间，PITR过程就会完成。
typedef structxl_xact_commit
{
TimestampTzxact_time; /* 提交时间 */
uint32 xinfo; /* 信息标记位 */
int nrels; /* RelFileNodes的数量 */
int nsubxacts; /* 子事务XIDs的数量 */
int nmsgs; /* 共享失效消息的数量 */
Oid dbId; /* MyDatabaseId, 数据库oid */
Oid tsId; /* MyDatabaseTableSpace, 表空间oid */
/* 在提交时需要丢弃的RelFileNode(s)数组*/
RelFileNode xnodes[1]; /* 变长数组 */
/* 紧接着已提交的子事务XIDs数组 */
/* 紧接着共享失效消息的数组 */
} xl_xact_commit;
typedef structxl_xact_abort
{
TimestampTz xact_time; /* 中止时间 */
int nrels; /* RelFileNodes的数量 */
int nsubxacts; /* 子事务XIDs的数量 */
/* 在中止时需要丢弃的RelFileNode(s)数组*/
RelFileNode xnodes[1]; /* 变长数组 */
/* 紧接着已提交的子事务XIDs数组 */
} xl_xact_abort;函数read_backup_label定义于src/backend/access/transam/xlog.c中。结构xl_xact_commit和xl_xact_abort定义于src/backend/access/transam/xlog.c中。 |
为什么可以用一般归档工具做基础备份？ 尽管数据库集簇可能是不一致的，但恢复过程是使数据库集簇达成一致状态的过程。由于PITR是基于恢复过程的，所以即使基础备份是一堆不一致的文件，它也可以恢复数据库集簇。因此，我们可以在没有文件系统快照功能或其他特殊工具的情况下，使用一般归档工具做基础备份。 |
往期精彩
出处：《PostgreSQL 指南：内幕探索》之基础备份与时间点恢复。
编辑：尹文敏
公司简介 | 招聘 | DTCC | 数据技术嘉年华 | 免费课程 | 入驻华为严选商城
zCloud | SQM | Bethune Pro2 | zData一体机 | MyData一体机 | ZDBM 备份一体机
Oracle技术架构 | 免费课程 | 数据库排行榜 | DBASK问题集萃 | 技术通讯
升级迁移 | 性能优化 | 智能整合 | 安全保障 | 架构设计 | SQL审核 | 分布式架构 | 高可用容灾 | 运维代维
云和恩墨大讲堂 | 一个分享交流的地方
长按，识别二维码，加入万人交流社群
请备注：云和恩墨大讲堂
549
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
