作者:文若
前言
本篇文章介绍 PostgreSQL 基于时间点恢复(point-in-time-recover)需要的条件及恢复过程,属于操作说明。
1. WAL 日志
WAL(Write Ahead Log) 日志优先写机制,常用于关系型数据库维护事务持久性、一致性,例如 MySQL 中的 Redo Log 也属于是 WAL 日志,不过在 MySQL 中如果要实现 PITR 要使用 Binlog 日志,这里我理解 MySQL 也可以用 Redo 去做复制的,也可以用 Redo 做 PITR, 但 MySQL 是多引擎架构,不仅有事务引擎,其它引擎不支持 Redo,所以才使用 Binlog 应用于 PITR 和主从复制。
在 PostgreSQL 只有事务引擎,所以 WAL 日志既可以应用于事务系统,也可以于主从同步和 PITR。
1.1 WAL 配置
想要实现 PITR 相当于一个全量备份 + 增量备份,那 WAL 就是用于做增量备份,此时就需要启用 WAL 归档:
wal_level = replica # minimal, replica, or logical
archive_mode = on # enables archiving; off, on, or always
# (change requires restart)
# 这里的目标是归档的目录,需要提前创建
archive_command = 'cp %p /data/pgsql12/archive/%f && echo %f >> /data/pgsql1
配置完成后需要重启数据库:
pg_ctl -D /data/pgsql12/data/ -l /data/pgsql12/logs/start.log restart
2. pg_basebackup
pg_basebackup [OPTION]...
参数 | 含义 |
---|---|
-D/–pg-data | 备份文件目录,表示将备份文件写入到那个目录下 |
-F/–format | 默认为p、可选择p、t |
-r/–max-rate | 传输数据的最大速率限制 |
-R/–write-recovery-conf | 输出用于replication的配置信息 |
-X, --wal-method | 指定复制wal日志的方式,有none、fetch、stream,推荐使用stream避免接收wal信息是源端日志被覆盖 |
-z, --gzip | 是否压缩,配合-F t使用 |
-Z, --compress=0-9 | 压缩等级,数字越大压缩率越大、越消耗CPU资源 |
-c, --checkpoint | 设置checkpoint的模式:fast、spread |
-C, --create-slot | 创建复制槽 |
-S, --slot=SLOTNAME | 指定复制槽名称 |
-l, --label=LABEL | 指定一个备份标识,便于运维人员后续的维护 |
-n, --no-clean | do not clean up after errors |
-N, --no-sync | do not wait for changes to be written safely to disk |
-P, --progress | 打印备份进度信息 |
-v, --verbose | 输出详细的信息 |
2.1 常用命令
用于基本的备份恢复常用命令:
pg_basebackup -D 备份文件目录 -v -P -Upostgres -h 127.0.0.1 -p5432 -R
3. 全备恢复实验
3.1 进行一个全备
pg_basebackup -D /data/pgsql12/backup -v -P -Upostgres -h 127.0.0.1 -p5432 -R
pg_basebackup: initiating base backup, waiting for checkpoint to complete
pg_basebackup: checkpoint completed
pg_basebackup: write-ahead log start point: 2/6D000028 on timeline 2
pg_basebackup: starting background WAL receiver
pg_basebackup: created temporary replication slot "pg_basebackup_74591"
2455778/2455778 kB (100%), 1/1 tablespace
pg_basebackup: write-ahead log end point: 2/6D000138
pg_basebackup: waiting for background process to finish streaming ...
pg_basebackup: syncing data to disk ...
pg_basebackup: base backup completed
3.2 写入增量数据
postgres=# update pgbench_accounts set abalance = 100 where bid = 41;
UPDATE 100000
postgres=# select pg_current_wal_lsn();
pg_current_wal_lsn
--------------------
2/70D63FD0
postgres=# select now();
now
-------------------------------
2023-08-08 13:51:34.475891+08
3.3 模拟备份恢复
此时最坏的事情发生了,需要恢复数据,首先需要先关闭数据库:
pg_ctl -D /data/pgsql12/data/ stop
waiting for server to shut down.... done
server stopped
将数据目录重命名,将基础备份
# 重命名备份目录
mv data data_bak
# 移动备份文件至数据目录
mv backup data
# 修改数据目录为 700 否则无法启动
# DETAIL: Permissions should be u=rwx (0700) or u=rwx,g=rx (0750).
chmod 700 /data/pgsql12/data/
修改数据目录下 postgresql.auto.conf 文件:
restore_command = 'cp /data/pgsql12/archive/%f %p > /data/pgsql12/archive/recovery.log 2>&1 '
# 通过 LSN 方式恢复
recovery_target_lsn='2/70D63FD0'
# 通过时间点的方式恢复 2 选 1
recovery_target_time = '2023-08-08 13:51:34'
# 达到恢复目标后,数据的动作 promote 表示可以直接接受连接,测试使用,生产恢复建议使用 pause(默认值)确认数据恢复好后,手动删除 recovery.signal 文件即可。
recovery_target_action = 'promote'
配置完这些后,重新启动数据库:
pg_ctl -D /data/pgsql12/data start -l /data/pgsql12/logs/start.log
验证刚才的增量数据是否已经恢复:
postgres=# select count(*) from pgbench_accounts where bid = 41 and abalance = 100;
count
--------
总结
PostgreSQL 想要实现 PITR 需要设置 wal_level 配置参数为 replica 或更高级别,且配置合理的归档机制和归档清理机制,本篇文章只引入恢复流程,一套生产环境备份恢复如何配置,我们将在下一篇文章介绍。
更多技术信息请查看云掣官网https://yunche.pro/?t=yrgw