使用低级API进行基础备份

dxiao2016

已于 2022-07-29 15:26:56 修改

阅读量156

点赞数

分类专栏： # 日常维护文章标签：数据库 postgresql

于 2022-07-29 15:21:19 首次发布

本文链接：https://blog.csdn.net/dongxiao_highgo/article/details/126054979

版权

日常维护专栏收录该内容

4 篇文章 0 订阅

订阅专栏

1.什么是基础备份？怎么获取基础备份？
在pg中，从8.0版本中引入了在线物理全备份，运行中的整个数据库集群的快照（即物理备份数据）被称为基础备份。

在pg中获取基础备份的方法：

1.使用系统low-level函数:pg_start_backup、pg_stop_backup以及一些shell命令(如cp、tar、rsync等）。
2.使用pg_basebackup工具。

本文主要讲述第一种方式，pg_basebackup的使用详见：
https://www.postgresql.org/docs/current/app-pgbasebackup.html

2.低级API的操作过程

【前提条件】
1).确保 WAL 归档已启用并正常工作。

wal_level = 'replica'
archive_mode = on
archive_command = 'test ! -f /opt/pg14/archivedir/%f && cp %p /opt/pg14/archivedir/%f'

【实现步骤】
1).启动基础备份。

postgres=# select pg_start_backup('label1');
 pg_start_backup 
-----------------
 0/28000028
(1 row)

在线备份总是在检查点开始时启动。默认情况下，pg_start_backup将等待下一个定期安排的检查点完成，这可能需要很长时间。如果您想尽快开始备份，请将true作为第二个参数传递给pg_start_backup，它将请求一个即时检查点，该检查点将使用尽可能多的 I/O 尽可能快地完成。

pg_start_backup主要执行以下几个操作：

1.强制服务器进入全页写模式（即使你设置了full_page_writes=off)。
2.执行checkpoint。
3.创建一个backup_label.old文件：
START WAL LOCATION: 0/28000028 (file 000000010000000000000028)
CHECKPOINT LOCATION: 0/28000060
BACKUP METHOD: pg_start_backup
BACKUP FROM: primary
START TIME: 2022-07-29 14:35:23 CST
LABEL: label1
START TIMELINE: 1

backup_label.old文件相关参数说明：

1.CHECKPOINT LOCATION：这是该函数创建的检查点被记录的LSN位置。当使用这个基础备份恢复数据库时，PostgreSQL从backup_label文件中获取“CHECKPOINT LOCATION”，并开始恢复过程。
2.BACKUP METHOD：标示用于进行基础备份的方法（pg_start_backup或pg_basebackup）。
3.START TIME：执行pg_start_backup时的时间戳。
4.LABEL：这是在调用pg_start_backup（LABEL）中指定的标签。

这时候可以用以下命令查询：

postgres=# select pg_is_in_backup();
 pg_is_in_backup 
-----------------
 t
(1 row)

2).执行备份，例如tar或cpio（不是pg_dump或pg_dumpall）

tar -zcvf /opt/pg14/data.tar.gz /opt/pg14/data

3).在步骤1的session连接中执行停止基础备份的操作。

postgres=# select pg_stop_backup(true);
NOTICE:  all required WAL segments have been archived
 pg_stop_backup 
----------------
 (0/28000138,,)
(1 row)

这将终止备份模式。在主节点上，它还会自动切换到下一个 WAL 段。在备用服务器上，无法自动切换 WAL 段，因此您可能希望在主服务器上执行select pg_switch_wal()以执行手动切换。切换的原因是为了安排在备份间隔期间写入的最后一个 WAL 段文件准备归档。

pg_stop_backup主要完成以下工作：

1.如果pg_start_backup强制打开了full_page_write，pg_stop_backup将会将其重置为非全页写模式。
2.创建备份历史文件（timeline.hostory）。
3.删除backup_label文件。（注：从基础备份恢复时，需要backup_label文件，其被复制到归档目录之后，在原始数据库集中就不再需要了。）

这时候可以用以下命令查询:

postgres=# select pg_is_in_backup();
 pg_is_in_backup 
-----------------
 f
(1 row)

3.备份之后的恢复操作
1).停止数据库并删除data。

[postgres@localhost bin]$ ./pg_ctl stop -D /opt/pg14/data
waiting for server to shut down....2022-07-29 14:58:30.123 CST [30169] LOG:  received fast shutdown request
2022-07-29 14:58:30.123 CST [30169] LOG:  aborting any active transactions
2022-07-29 14:58:30.124 CST [30169] LOG:  background worker "logical replication launcher" (PID 30177) exited with exit code 1
2022-07-29 14:58:30.124 CST [30171] LOG:  shutting down
2022-07-29 14:58:30.349 CST [30169] LOG:  database system is shut down
 done
server stopped
[postgres@localhost bin]$ rm -rf /opt/pg14/data
[postgres@localhost bin]$

2).将备份的data.tar.gz解压缩。

tar -zxvf /opt/pg14/data.tar.gz -C /opt/pg14

3).修改postgresql.conf配置文件。

restore_command = 'cp /opt/pg14/archivedir/%f %p'
recovery_target_name = 'label1'

4).重启数据库，完成恢复redo。

[postgres@localhost bin]$ ./pg_ctl start -D /opt/pg14/data
pg_ctl: another server might be running; trying to start server anyway
waiting for server to start....2022-07-29 15:03:20.062 CST [33438] LOG:  starting PostgreSQL 14.0 on x86_64-pc-linux-gnu, compiled by gcc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-44), 64-bit
2022-07-29 15:03:20.065 CST [33438] LOG:  listening on IPv4 address "0.0.0.0", port 5899
2022-07-29 15:03:20.065 CST [33438] LOG:  listening on IPv6 address "::", port 5899
2022-07-29 15:03:20.066 CST [33438] LOG:  listening on Unix socket "/tmp/.s.PGSQL.5899"
2022-07-29 15:03:20.071 CST [33439] LOG:  database system was interrupted; last known up at 2022-07-29 14:35:23 CST
2022-07-29 15:03:20.087 CST [33439] LOG:  redo starts at 0/28000028
2022-07-29 15:03:20.087 CST [33439] LOG:  invalid record length at 0/28000110: wanted 24, got 0
2022-07-29 15:03:20.087 CST [33439] LOG:  redo done at 0/280000D8 system usage: CPU: user: 0.00 s, system: 0.00 s, elapsed: 0.00 s
2022-07-29 15:03:20.098 CST [33438] LOG:  database system is ready to accept connections
 done
server started