数据救星，PITR让高斯数据库"进退自如"！

在实际业务场景中，客户数据库难免会出现数据损毁、数据丢失、数据误删除等故障场景。

传统数据库采取周期性备份策略，恢复耗时长，时间颗粒度大，导致客户业务受损，接下来给大家分享一个国产数据库openGauss基于PITR的恢复，会让你打开眼界。

1.何为PITR？

PITR（Point-in-Time Recovery）是数据库的一项重要功能，它允许你在数据库发生故障或数据丢失时恢复到特定的时间点。以openGauss为例，PITR 的工作原理是通过使用WAL日志来记录数据库的所有变更操作，从而实现对数据库状态的恢复，可以支持恢复到备份归档数据之后的任意时间点。

2.PITR恢复要点

PITR恢复流程:
1.将物理备份的文件替换目标数据库目录。
2.删除数据库目录下pg_xlog/中的所有文件。
3.将归档的WAL日志文件复制到pg_xlog文件中（
4.在数据库目录下创建恢复命令文件recovery.conf，指定数据库恢复的程度。
5.启动数据库。
6.连接数据库，查看是否恢复到希望预期的状态。
7.若已经恢复到预期状态，通过pg_xlog_replay_resume()指令使主节点对外提供服务。
#### 恢复目标设置(四选一) ####
1.还原到一个使用pg_create_restore_point()创建的还原点
recovery_target_name = 'restore_point_1' 
2.还原到一个指定时间戳
recovery_target_time = '2020-01-01 12:00:00'  
3.还原到一个事务ID
recovery_target_xid = '3000' 
4.还原到日志的指定LSN点
recovery_target_lsn = '0/0FFFFFF'
--声明是否在指定恢复目标之后停止(true) 或 之前停止(false),
不支持recovery_target_name 配置
recovery_target_inclusive = true

3.PITR恢复流程

3.1 全量物理备份

使用gs_basebackup全量备份
创建备份文件存储目录，gs_basebackup备份
数据库需要处于开启状态
$ mkdir -p /home/omm/gs_bak
$ gs_basebackup -D /home/omm/gs_bak -p 15400

3.2 准备测试数据

1）记录操作的起始位置
--创建测试数据
openGauss=# \c testdb
testdb=# \dt
                          List of relations
 Schema |  Name   | Type  | Owner |             Storage              
--------+---------+-------+-------+----------------------------------
 public | test    | table | omm   | {orientation=row,compression=no}
 public | testbak | table | omm   | {orientation=row,compression=no}
(2 rows)
-- 创建一个还原点restore_point_1
testdb=# select pg_create_restore_point('restore_point_1');
 pg_create_restore_point 
-------------------------
0/F00B638
(1 row)
2）创建测试数据t1表(源库)
create table t1(name varchar(50));
insert into t1 values('This is restore_point_1');
此时我们可以记录下时间2024-09-18 12:00:00

3.3 基于时间点恢复

1)将备份文件恢复到目标库
#恢复（在本机恢复到另外的data目录/home/omm/data/db1）
创建恢复数据库的data目录，将备份恢复到新建目录中/home/omm/data/db1（恢复新库的data目录）：
mkdir -p /home/omm/data/db1
cd /home/omm/data/db1
cp -r /home/omm/gs_bak/* /home/omm/data/db1/
2)拷贝源库的WAL日志至归档目录,然后删除WAL日志(pg_xlog下文件)
拷贝源库的WAL日志至归档路径
cp /openGauss/data/dn/pg_xlog/* /archivelog/
 删除数据库目录下pg_xlog/中的所有文件。
cd /openGauss/data/dn/pg_xlog/
rm -rf *
3)第一阶段恢复(还原点恢复restore_point_1)
配置recovery.conf文件(基于还原点restore_point_1恢复)
--创建recovery.conf文件
cd /home/omm/data/db1/
cat> recovery.conf<<EOF
restore_command = 'cp /archivelog/%f %p'
archive_cleanup_command = 'pg_archivecleanup /archivelog  %r'
## 恢复到指定的还原点restore_point_1,此时还没有创建表t1
recovery_target_time = '2024-09-18 12:00:00'  
recovery_target_inclusive = true
EOF
--由于在本机操作，关闭源数据库,避免port冲突
$ gs_om -t stop
--启动恢复目标数据库并查看数据，数据目录： /home/omm/data/db1
$ gs_ctl start -D  /home/omm/data/db1

3.4 结束PITR

手动结束 PITR 状态
当未将数据库恢复至最新时刻状态时，
此时需要手动结束PITR恢复任务。
-- 查询数据库恢复状态
testdb=# select pg_is_in_recovery();
 pg_is_in_recovery 
-------------------
 t
(1 row)
 -- 结束恢复，使机器对外提供读写服务
testdb=# select pg_xlog_replay_resume();
 pg_xlog_replay_resume
-----------------------
-- 查询数据库恢复状态(已结束)
testdb=# select pg_is_in_recovery();
 pg_is_in_recovery 
-------------------
 f
(1 row)
--可以看到目前数据库可以读写了
testdb=# drop table testbak;
DROP TABLE

4.总结

PITR 需要通过 pg_basebackup 和 archive_command 配合才能保证恢复到预期的时间点，但数据量很大的时候做一次 pg_basebackup 耗时非常长，可以通过增量备份与全备合并的方式，以减少磁盘 IO 和网络开销。