pg_basebackup备份恢复实战

本文主要是介绍pg_basebackup备份恢复实战，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

首先PG需要开启归档模式,wal_level至少设置为replica

1.用脚本不停往一个测试表中写数据:

create table t1(id int primary key,name varchar(10));

shell中执行:

i=1;while true; do psql -p15432 -d test -c "insert into t1 values($i,'aa');";echo $i; i=$(($i+1)); sleep 1; done

INSERT 0 1

当前的PGDATA如下:

PGDATA=/data/pgsql-12

备份归档路径为/data/pg_arch

2.在某一个时刻发起备份命令:

pg_basebackup -D /var/lib/pgsql/pg_backup/ -Ft -Pv -U postgres -p15432 -R

# -D 空文件，没有该目录会自动创建

# F 格式话

# t 打包为tar包

# Pv显示备份的详细过程

# -u 用户

# -p 端口

备份完成的时候,查看那个测试表的数据大概写了20多条

3.再过了一段时间之后关闭pg

#先停止插入脚本,关闭pg的时候写了大概119条

INSERT 0 1

119

#切换日志

select pg_switch_wal();

#检查当前的lsn之后关闭PG

select pg_walfile_name(pg_current_wal_lsn());

systemctl stop postgresql-12

4.恢复备份文件和日志文件

#备份一下原来的PGDATA

cd /data

mv pgsql-12 pgsql-12.bak2

#创建新的PGDATA目录,并且设置为700权限

mkdir pgsql-12

chmod 700 pgsql-12

#恢复备份文件

cd /var/lib/pgsql/pg_backup/

tar -xvf base.tar -C /data/pgsql-12

tar -xvf pg_wal.tar -C /data/pg_arch

5.设置恢复模式

cd /data/pgsql-12

vi postgresql.auto.conf

追加:

其中有多个恢复配置:

#立刻恢复:

restore_command = 'cp /data/pg_arch/%f %p'

recovery_target = 'immediate'

#可以按时间线恢复到最新

restore_command = 'cp /data/pg_arch/%f %p'

recovery_target_timeline = 'latest'

#按时间点恢复

restore_command = 'cp /data/pg_arch/%f %p'

recovery_target_time = '2023-03-19 16:16:16.007657+08'

#指定lsn恢复,这里我们使用这个lsn进行恢复

restore_command = 'cp /data/pg_arch/%f %p'

recovery_target_lsn = '0/150010E0'

#指定回放xid ,可以手工查询select txid_current();或者是通过pg_waldump查看归档的wal log

restore_command = 'cp /data/pg_arch/%f %p' --在备份指定其回放时，从归档路径中寻找历史wal

recovery_target_xid = '816' --执行要回放的事务ID节点

6.创建恢复文件,提示pg启动时候需要进行恢复

touch /data/pgsql-12/recovery.signal

7.启动数据库

pg_ctl -D /data/pgsql-12 start

这里日志里面显示了恢复wal日志信息:

2024-05-10 23:01:22.846 CST [27501] LOG: entering standby mode

2024-05-10 23:01:22.864 CST [27501] LOG: restored log file "000000010000000000000014" from archive

2024-05-10 23:01:22.894 CST [27501] LOG: redo starts at 0/14000028

2024-05-10 23:01:22.896 CST [27501] LOG: consistent recovery state reached at 0/14001668

2024-05-10 23:01:22.896 CST [27499] LOG: database system is ready to accept read only connections

2024-05-10 23:01:22.913 CST [27501] LOG: restored log file "000000010000000000000015" from archive

2024-05-10 23:01:22.958 CST [27501] LOG: restored log file "000000010000000000000016" from archive

2024-05-10 23:01:22.982 CST [27501] LOG: recovery stopping after WAL location (LSN) "0/16000028"

2024-05-10 23:01:22.982 CST [27501] LOG: recovery has paused

2024-05-10 23:01:22.982 CST [27501] HINT: Execute pg_wal_replay_resume() to continue.

#查询数据

test=# select count(*) from t1;

count

-------

119 --数据和停止的时候保持一致

(1 row)

此时数据库为只读模式,还需要修改到读写模式

8.数据库切换为读写

select pg_wal_replay_resume();

9.删除recovery.signal文件

rm -rf /data/pgsql-12/recovery.signal

#关于恢复设置,官方文档如下:

27.2. Recovery Target Settings

By default, recovery will recover to the end of the WAL log. The following parameters can be used to specify an earlier stopping point. At most one of recovery_target, recovery_target_lsn, recovery_target_name, recovery_target_time, or recovery_target_xid can be used; if more than one of these is specified in the configuration file, the last entry will be used.

recovery_target = 'immediate'

This parameter specifies that recovery should end as soon as a consistent state is reached, i.e., as early as possible. When restoring from an online backup, this means the point where taking the backup ended.

Technically, this is a string parameter, but 'immediate' is currently the only allowed value.

recovery_target_name (string)

This parameter specifies the named restore point (created with pg_create_restore_point()) to which recovery will proceed.

recovery_target_time (timestamp)

This parameter specifies the time stamp up to which recovery will proceed. The precise stopping point is also influenced by recovery_target_inclusive.

recovery_target_xid (string)

This parameter specifies the transaction ID up to which recovery will proceed. Keep in mind that while transaction IDs are assigned sequentially at transaction start, transactions can complete in a different numeric order. The transactions that will be recovered are those that committed before (and optionally including) the specified one. The precise stopping point is also influenced by recovery_target_inclusive.

recovery_target_lsn (pg_lsn)

This parameter specifies the LSN of the write-ahead log location up to which recovery will proceed. The precise stopping point is also influenced by recovery_target_inclusive. This parameter is parsed using the system data type pg_lsn.

The following options further specify the recovery target, and affect what happens when the target is reached:

recovery_target_inclusive (boolean)

Specifies whether to stop just after the specified recovery target (true), or just before the recovery target (false). Applies when recovery_target_lsn, recovery_target_time, or recovery_target_xid is specified. This setting controls whether transactions having exactly the target WAL location (LSN), commit time, or transaction ID, respectively, will be included in the recovery. Default is true.

recovery_target_timeline (string)

Specifies recovering into a particular timeline. The default is to recover along the same timeline that was current when the base backup was taken. Setting this to latest recovers to the latest timeline found in the archive, which is useful in a standby server. Other than that you only need to set this parameter in complex re-recovery situations, where you need to return to a state that itself was reached after a point-in-time recovery. See Section 25.3.5 for discussion.

recovery_target_action (enum)

Specifies what action the server should take once the recovery target is reached. The default is pause, which means recovery will be paused. promote means the recovery process will finish and the server will start to accept connections. Finally shutdown will stop the server after reaching the recovery target.

The intended use of the pause setting is to allow queries to be executed against the database to check if this recovery target is the most desirable point for recovery. The paused state can be resumed by using pg_wal_replay_resume() (see Table 9.81), which then causes recovery to end. If this recovery target is not the desired stopping point, then shut down the server, change the recovery target settings to a later target and restart to continue recovery.

The shutdown setting is useful to have the instance ready at the exact replay point desired. The instance will still be able to replay more WAL records (and in fact will have to replay WAL records since the last checkpoint next time it is started).

Note that because recovery.conf will not be renamed when recovery_target_action is set to shutdown, any subsequent start will end with immediate shutdown unless the configuration is changed or the recovery.conf file is removed manually.

This setting has no effect if no recovery target is set. If hot_standby is not enabled, a setting of pause will act the same as shutdown.