zoukankan      html  css  js  c++  java
  • 《PostgreSQL 指南:内幕探索》之基础备份与时间点恢复(上)

    墨墨导读:最近电子工业出版社博文视点出版了《PostgreSQL指南:内幕探索》,日前「数据和云」公众号推荐了这本书并赠送了五本,百多位用户参与,几十条留言未能放出,为了让大家更好地学习开源数据PostgreSQL,经出版社官方授权,刊载本书部分章节内容以飨读者,本文节选了第十章《基本备份与时间点恢复》10.1-10.2。


    此外,我们也成立PostgreSQL学习社群,技术探讨、资料分享、大牛解答,欢迎加入一起进步,入群方式见文末。


    在线数据库备份大致可分为逻辑备份和物理备份两类,它们各自都有优点和缺点。逻辑备份有一个缺点,即执行需要花费大量的时间。特别是对于大型数据库而言,需要花费很长时间进行备份,而从备份数据中恢复数据库可能需要更长的时间。相反,物理备份可以在相对较短的时间内备份和恢复大型数据库,因此在实际系统中,其是一个非常重要且实用的功能。


    在PostgreSQL中,自8.0版本开始提供了在线的全量物理备份,整个数据库集簇(即物理备份数据)的运行时快照被称为基础备份。


    PostgreSQL还在8.0版中引入了时间点恢复(Point-In-Time Recovery,PITR)。这一功能可以将数据库恢复至任意时间点,这通过使用一个基础备份和由持续归档生成的归档日志来实现。例如,即使你犯了一个严重的错误(如TRUNCATE所有的表),此功能还可以将数据库恢复至错误发生之前的时刻。


    本文描述了以下主题:


    • 基础备份

    • 时间点恢复(PITR)的工作原理

    • 时间线与时间线历史文件

    • 时间点恢复与时间线历史文件


    在7.4或更低版本中,PostgreSQL仅支持逻辑备份(全量逻辑备份、部分逻辑备份和数据导出)。


    基础备份



    640?wx_fmt=png

    制作基础备份


    使用底层命令进行基本备份的标准过程上图所示,具体步骤如下:


    1. 发出pg_start_backup命令。

    2. 使用你想用的归档命令获取数据库集簇的快照。

    3. 发出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个操作:


    1. 强制进入整页写入模式。

    2. 切换到当前的WAL段文件(8.4或更高版本)。

    3. 执行检查点。

    4. 创建backup_label文件 —— 该文件创建于基本目录顶层中,包含有关该基本备份本身的关键信息,如检查点的检查点位置。


    第3个和第4个操作是该命令的核心。第1和第2个操作是为了更可靠地恢复数据库集簇。


    备份标签backup_label文件包含以下7个项目:


    1. 检查点位置 —— 该命令所创建检查点的LSN位置。

    2. WAL开始位置——这不是给PITR用的,而是为第11章描述的流复制准备的。它被命名为START WAL LOCATION,因为复制模式下的备用服务器在初始启动时只读取一次该值。

    3. 备份方法——这是用于进行此基本备份的方法,如pg_start_backup或pg_basebackup。

    4. 备份来源 —— 说明此备份是从主库还是备库拉取。

    5. 开始时间 —— 这是执行pg_start_backup时的时间戳。

    6. 备份标签 —— 这是pg_start_backup中指定的标签。

    7. 开始时间线 —— 这是备份开始的时间线,为了进行正常的检查,在版本11.0中被引入。

     

    备份标签

    一个9.6版本中备份标签的实际例子如下所示:

    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: 2018-7-9 11:45:19 GMT  LABEL: Weekly Backup


    可以想象,当使用此基础备份恢复数据库时,PostgreSQL从backup_label文件中取出检查点位置CHECKPOINTLOCATION,接着从归档日志中的合适位置读取检查点记录,然后从检查点记录中获取重做点的位置,最后从重做点开始进行恢复。


    • pg_stop_backup


    pg_stop_backup执行以下5个操作以完成备份:


    1. 如果pg_start_backup打开了整页写入,那么关闭整页写入。

    2. 写入一条备份结束的XLOG记录。

    3. 切换WAL段文件。

    4. 创建一个备份历史记录文件 —— 此文件包含backup_label文件的内容,以及已执行pg_stop_backup的时间戳。

    5. 删除backup_label文件 —— 从基础备份恢复需要backup_label文件,不过一旦被复制,原始的数据库集簇就不需要该文件了。


    备份历史文件的命名方法如下所示:

    {WAL段文件名}.{基础备份开始时的偏移量}.backup


    时间点恢复(PITR)的工作原理


    下图展示了PITR的基本概念。PITR模式下的PostgreSQL会在基础备份上重放归档日志中的WAL数据,从pg_start_backup创建的重做点开始,恢复到你想要的位置为止。在PostgreSQL中,想要恢复到的位置被称为恢复目标。


    640?wx_fmt=png

    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过程几乎与常规恢复过程一模一样,唯一的区别只有以下两点:


    1. 从哪里读取WAL段/归档日志?

      1. 正常恢复模式 —— 来自基础目录下的pg_xlog子目录(在10.0或更高版本中为pg_wal子目录)。

      2. PITR模式 —— 来自配置参数archive_command中设置的归档目录。

    2. 从哪里读取检查点位置?

      1. 正常恢复模式 —— 来自pg_control文件。

      2.    PITR模式 —— 来自backup_label文件。


    PITR流程概述如下:


    1. 为了找到重做点,PostgreSQL使用内部函数read_backup_label从backup_label文件中读取CHECKPOINTLOCATION的值。

    2. PostgreSQL从recovery.conf中读取一些参数值,在此例中为restore_command和recovery_target_time。

    3. 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是基于恢复过程的,所以即使基础备份是一堆不一致的文件,它也可以恢复数据库集簇。因此,我们可以在没有文件系统快照功能或其他特殊工具的情况下,使用一般归档工具做基础备份。


    往期精彩



    1. 从Oracle到PostgreSQL:Storage Index 特性 vs BRIN 索引

    2. PostgreSQL在Linux上的RPM和源码安装

    3. “王者对战”之 MySQL 8 vs PostgreSQL 10

    4. PostgreSQL的clog—从事务回滚速度谈起

    5. 从Oracle到PostgreSQL:动态性能视图 vs 标准统计视图

    6. 最稳定可靠,PostgreSQL 12.1版本正式发布!


    出处:《PostgreSQL 指南:内幕探索》之基础备份与时间点恢复。


    640?wx_fmt=png

    640?wx_fmt=jpeg

    公司简介  | 招聘 | DTCC | 数据技术嘉年华 | 免费课程 | 入驻华为严选商城

      640?wx_fmt=jpeg

    zCloud | SQM | Bethune Pro2 zData一体机 | MyData一体机 | ZDBM 备份一体机

    640?wx_fmt=jpeg

    Oracle技术架构 | 免费课程 | 数据库排行榜 | DBASK问题集萃 | 技术通讯 

    640?wx_fmt=jpeg

    升级迁移 | 性能优化 | 智能整合 安全保障 |  架构设计 | SQL审核 | 分布式架构 | 高可用容灾 | 运维代维

    云和恩墨大讲堂 | 一个分享交流的地方

    长按,识别二维码,加入万人交流社群


    640?wx_fmt=jpeg

    请备注:云和恩墨大讲堂

  • 相关阅读:
    装饰者模式
    代理模式
    享元模式
    模板模式
    命令模式
    建造者模式
    单例模式
    观察者模式
    迭代器模式
    访问者模式
  • 原文地址:https://www.cnblogs.com/hzcya1995/p/13312026.html
Copyright © 2011-2022 走看看