POSTGRESQL V12 PG_BASEBACKUP 进行PITR恢数据与PITR 原理

努力就应该有回报, 大多数人大多数的时候的努力都是期望有回报的,没有回报的努力,如同没有工资的工作,和一刻都没有爱着你的人,真心的付出, 所以大多数的努力都是有时限的,有忍耐度的, 而对一个事务持续的投入,努力,不记回报可能吗?  可能,因为那是真爱.

POSTGRESQL 12版本中通过pg_basebackup 备份数据并且进行PITR 数据恢复这个问题的需要谈谈. 顺便捋一捋POSTGRESQL 整个数据库备份的原理和恢复的原理.

POSTGRESQL 备份的正库备份的基本命令是pg_basebackup 命令,与MYSQL 只提供逻辑备份相比, PG本身提供 逻辑备份 和 物理备份的两种方式.

pg_basebackup 是PG 提供的物理备份的方式,通过pg_basebackup 将正在运行的数据库进行整体的物理的备份.

熟悉MYSQL的同学必然会提出那么通过XTRABAKCUP 的时候我们还会对日志的问题进行处理,保证我备份的数据是有时间点的性的. 那么pg_basebackup 这个命令对于正在运行的数据库中的日志是怎么处理的.

实际上PG的物理备份是从POSTGRESQL 8.0 就开始支持的功能,同时也是在这个版本支持了PITR ,point in time recovery的功能,指定时间段进行数据备份的功能.

pg_basebackup 实际上工作有三个步骤组成 1 停止日志写, 2 备份数据和日志文件  3 打开日志写 , 所以在PG_BASEBACKUP 工作中是没有锁表这么一说的. 因为这样操作是不需要去锁什么表的.

我们通过pg_basebackup 来备份相关的数据库

pg_basebackup -h localhost -p 5432 -U postgres -D /pgdata/inbackup -Fp -Xs -P

具体pg_basebackup 备份的后的目录和 backup_label 信息

包含了开始备份的wal log 的位置, checkpoint 的位置, 备份的方式streamed 备份是从哪个服务器上操作的,以及备份的开始的时间

数据恢复也很简单

我现在将数据库停止,并且将原有的数据目录删除,然后将备份的文件拷贝到原有的目录中启动数据库

到目前为止我们仅仅是简单的进行了数据的全备份和全量的恢复 ,PITR到底是怎么实现的. 并且在POSTGRESQL 12V 版本中的改变

我们先做相关的实验,在来说说到底是怎么回事,实验的目的先讲清,在实际的数据库恢复过程中,这样的做法是不会使用, 这个实验的目的主要是为了清晰的了解postgresql的主要PITR的过程和浅层的原理.

实验主要要做的

在数据库中创建一个表,插入数据,然后备份, 在删除这个表, 通过PITR的方式回复这个数据表

前期的数据准备步骤

在上图删除数据的时候,实际上已经做完了备份,这点需要注意

在备份完毕在删除数据库,停止数据库

清理原数据库的目录里面的数据, 将备份的数据拷贝回数据库的目录中

在原有的数据目录产生recovery.signal 文件,并且在 postgresql.auto.conf加入如下的信息

restore_command = 'cp /pgdata/archive/%f %p'

recovery_target_time = '2021-03-04 15:55:09'

touch /pgdata/data/recovery.signal

启动数据库后,数据库会在指定的时间点停止. 此时数据库可以进行联机.

然后执行.

之前删除的数据已经回来了.

那么我们在返回来看原理

PITR 主要的功能是在备份后操作的数据进行恢复,那么从上面的

restore_command = 'cp /pgdata/archive/%f %p'

recovery_target_time = '2021-03-04 15:55:09'

两个配置中可以看出

1  要恢复备份后在变动的数据,必然有wal日志的接入,并且这个日志如果在archive 日志中,那是要被重新拷贝到原来的日志目录中在进行使用,

2  通过指定时间是PITR常用的方式通过时间的方式来指定是常用的方式.

实际上PITR 是在全备的基础上,从pg_start_backup 开始后的任意时间点进行数据的恢复,从PG12 开始没有recovery.conf 文件后,就需要在恢复的时候在数据目录产生 recovery.signal 文件,以及 在配置文件中的recovery的配置,具体看前几期的关于PG12 的recovery 文件的文字.

其实PITR 并不神秘,大白话就是在数据恢复的FULL 的过程中, 卡到你的时间点而已,如果你不提供时间点,他就将所有的日志都应用完. 在恢复完毕后

会产生history 文件,并且还会在archive 日志目录也产生同样的文件,文件中会包含确认和终止的时间戳,在postgresql进行恢复的过程中,重放XLOG ,每个重放的操作都会对时间点进行比较,到设定的时间点为止.

PITR 过程与普通的数据恢复的过程基本相同,不同点主要在于

1 普通的恢复读取的日志是从pg_wal中读取,而PITR的过程会从archive_command中读取archive 中的数据

2 普通的恢复的checkpoint的位置获取是从pg_control 文件中,而PITR是从backup_label中获得的文件PITR的过程