详解完整恢复及基于时间点的恢复


难度 中等

一、 恢复配置详解

1. 归档恢复配置

主库 postgresql.conf

  • archive_mode:是否开启归档,若要用归档方式搭建从库则必须开启
  • archive_command:归档命令,通常是cp
  • archive_timeout:在指定秒数后强制切换一个wal文件,注意被切换的文件会跟正常文件一样大,所以这个参数设置过小会导致wal大量占用空间

从库 recovery.conf

  • restore_command:告诉从库如何获取归档WAL文件段的命令,通常是cp

  • archive_cleanup_command:从库清理已不需要的wal日志,避免磁盘空间撑满

  • recovery_end_command:恢复完成后执行指定命令

2. recovery target设置

下列选项进指定恢复目标

recovery_target:目前只能为immediate,指定恢复在达到一致状态后尽快结束,打开DB

recovery_target_name:由pg_create_restore_point()创建的还原点,用于恢复到指定还原点

recovery_target_time:恢复到指定时间点,最常用

recovery_target_xid:恢复到指定事务ID,在指定事务之前提交的事务将被恢复。注意事务ID是顺序分配的,但后分配的事务ID可能先完成。精确的停止点受recovery_target_inclusive影响。

recovery_target_lsn:恢复到WAL的指定LSN,精确的停止点也受 recovery_target_inclusive的影响。

下列选项进一步指定恢复目标,并且影响到达目标时会发生什么
recovery_target_inclusive:布尔值,指定恢复到恢复目标之后还是之前,默认为之后(true)

recovery_target_timeline:指定恢复的时间线。默认只沿着基础备份建立时时间线恢复而不会切换到新的时间线。通常设置为latest,这样便可恢复到该离当前最近的时间线。

recovery_target_action:指定在达到恢复目标时服务器采取的动作。

  • pause:默认值,表示恢复将被暂停
  • promote:表示恢复结束且服务器将开始接受连接
  • shutdown:表示在达到恢复目标之后停止服务器。

使用pause的目的是恢复到最想要的位置。当确定已恢复到最想要的位置,可以使用pg_wal_replay_resume()结束暂停的状态,这会让恢复终结。如果恢复的位置不是想要的,那么关闭服务器,重新设置恢复目标,然后启动DB继续恢复。

注意在recovery_target_action被设置为shutdown时,recovery.conf将不会被重命名,任何后续的启动都将会以立刻关闭为终结,除非该配置被改变或者recovery.conf文件被手工移除。

如果没有设置恢复目标,这个设置没有效果。如果没有启用hot_standby,pause设置的动作将和shutdown一样。

 http://postgres.cn/docs/10/recovery-target-settings.html  

二、 时间线——pg中的平行世界

这个概念感觉类似Oracle的化身(Incarnation)和小说电影里的平行世界。虽然可以通过PITR恢复到之前的时间点,相当于小说里时光倒流主角重生了,但回到的不再是原来的世界,而是去到了一个平行世界。

1. 为什么需要时间线

还是拿小说举例子,重生的主角通常都担心自己做了一点什么事情会影响历史的进程,当然小说电视剧里主角的影响最后总是会被历史修复。那pg能够修复回退后的更改吗?

比如某天17点开发来找你说误操作了,要恢复到15点的数据。好的,我们给他恢复了。恢复之后业务运行了半个小时,开发又来找你说,刚才搞错了应该恢复到16点的数据,能够做到吗?

如果没有时间线的概念而在15点后又没另外做备份,能用之前的备份+归档恢复到16点的数据吗?显然是不能的,因为在DB运行过程中产生了与旧WAL文件重名的文件,归档时覆盖原来的日志,导致恢复到16点需要的WAL文件丢失。

阿里云的博客有张图挺形象的

pg 备份恢复(三)—— 详解完整恢复及基于时间点的恢复_文件名

2. 时间线的作用

为了解决这个问题,PostgreSQL引入了时间线的概念。每当归档文件恢复完成,创建一个新的时间线用来区别新生成的WAL记录。区别的方式很简单,就在WAL文件名里加入了时间线ID,由时间线和日志序号来组成WAL文件名,不会覆盖由以前的时间线生成的WAL。

源码实现如下:

有了时间线,只要备份和归档还在,我们小说的主角就能够重生到任意时间点了,但每次其实都相当于去到了一个平行世界,保证主角重生之后的所作所为不影响原来的世界。每个时间线也类似一个分支,在当前时间线的操作不会对其他时间线WAL造成影响。

pg 备份恢复(三)—— 详解完整恢复及基于时间点的恢复_hive_02

3. 何时会产生新时间线

  • 利用归档进行恢复,完整恢复和PITR都会
  • 从库激活为主库,即执行 pg_ctl promote –D $PGDATA

4. history文件

  • 何时产生:与时间线相同,每当创建一个新的时间线,pg都会创建一个“时间线历史”文件,文件名类似.history。
  • 内容:原时间线history文件的内容+一条当前时间线切换记录。

假设数据库恢复启动后,切换到新的时间线ID=5,那么文件名就是00000005.history ,该文件记录了自己是从什么时间哪个时间线什么原因分出来的(相当于主角重生之后还有记忆),该文件可能含有多行记录,每个记录的内容格式如下:

例如:

当数据库在从包含多个时间线的归档中恢复时,这些history文件允许系统选取正确的WAL文件,当然,它也能像WAL文件一样被归档到WAL归档目录里。历史文件只是很小的文本文件,所以保存它们的代价很小。

当我们在recovery.conf指定目标时间线tli进行恢复时,程序首先寻找.history文件,根据.history文件里面记录的时间线分支关系,找到从pg_control里面的startTLI到tli之间的所有时间线对应的日志文件,再进行恢复。

参考

 http://mysql.taobao.org/monthly/2015/07/03/

待补充


文章作者: growdu
版权声明: 本博客所有文章除特別声明外,均采用 CC BY 4.0 许可协议。转载请注明来源 growdu !
  目录
分类导航
随笔2 AI27 算法1 计算机基础13 博客搭建7 ChatGPT2 集群63 计算机通信1 数据库34 数据库深入80 DPDK26 Docker11 Elasticsearch4 编辑工具4 FAQ1 Go Web1 hometown2 编程语言16 网络9 OPC1 Linux38 openGauss4 页面12 PostgreSQL54 程序员自我修养1 协议11 成长之路1 stock1 存储5 工具20 VPP18 视频作品1 Vue13 Web1 代码示例11 数据库15 BenchmarkSQL1 PostgreSQL 源码修炼之路14
最热文章
1
13 逻辑复制深入
数据库深入🔥 1570
2
0 Postgresql存储、索引及系统优化、主备切换
PostgreSQL🔥 1495
3
一文读懂openguass dcf网络模块
集群🔥 1420
4
逻辑复制源码分析
数据库深入🔥 1327
5
PostgreSQL 分区表:从一行 `PARTITION BY` 到路由热路径的全链路拆解
数据库🔥 1094
6
applyparallelworker.c 之 LA 端源码深度解析:Leader Apply Worker 的指挥中枢
数据库深入🔥 1082
7
PostgreSQL Background Worker 全解:从 `RegisterBackgroundWorker` 到逻辑复制 4 类 worker 的全生命周期
数据库🔥 1078
8
PostgreSQL的后台进程walsender分析 - 关系型数据库 - 亿速云
PostgreSQL🔥 1033
9
PostgreSQL 逻辑复制的监控:六张视图 + 一组可执行 SQL,把 publisher/subscriber 的速率与健康度彻底看透
数据库🔥 1032
10
PostgreSQL 逻辑复制支持 DDL 之后:DDL 与 DML 的时序难题(重点:分区表)
数据库🔥 999
11
reorderbuffer.c 源码深度解析:PostgreSQL 逻辑复制的"事务重组引擎
数据库深入🔥 953
12
PostgreSQL 内核开发:读取一张表的 9 步标准流程与缓存全景
数据库🔥 938
13
从 `postgres` 二进制到生产级守护 —— PostgreSQL 最外层模块与启动全流程拆解
数据库🔥 936
14
支持逻辑复制同步 DDL 适配 SQL Server 方案
数据库深入🔥 934
15
PostgreSQL 逻辑复制的 ReorderBuffer 与事务机制:从一行 WAL 到一致性变更流的全链路绑定
数据库🔥 913
16
DDL同步架构(美化版)
数据库深入🔥 908
17
PostgreSQL Latch 机制详解:从一行 SetLatch 到 epoll 的内核之旅
数据库🔥 871
18
pgbench 源码全解:一个 C 文件如何撑起 PostgreSQL 官方压测工具
数据库🔥 860
19
PostgreSQL libpq 机制与缓冲区详解
数据库🔥 850
20
PostgreSQL 逻辑复制 spill 文件深度剖析:从 `xid-*.spill` 到 TPC-C 的增长方程
数据库🔥 845