OpenGauss备份恢复

OpenGauss备份恢复

gs_basebackup工具

gs_basebackup备份：
用于基础的物理备份，可以实现对数据文件的二进制拷贝备份，实现原理是使用了复制协议。远程执行gs_basebackup时，需要使用系统管理员账户。

备份前提条件：
备份客户端可以正常连接openGauss数据库；
pg_hba.conf中需要配置允许复制链接，且该连接必须由一个系统管理员建立；
如果xlog传输模式为stream模式，则需要配置max_wal_senders的数量, 至少有一个可用；
如果xlog传输模式为fetch模式，则需要把wal_keep_segments参数设置得足够高，确保在备份完毕之前日志不会被移除；

特点：
gs_basebackup 支持全量备份，不支持增量；
gs_basebackup 支持简单备份格式和压缩备份格式；
gs_basebackup 在备份包含绝对路径的表空间时，不能在同一台机器上进行备份，会产生冲突；
若打开增量检测点功能且打开双写, gs_basebackup也会备份双写文件；
若pg_xlog目录为软链接，备份时将不会建立软链接，会直接将数据备份到目的路径的pg_xlog目录下；
备份过程中收回用户的备份权限，可能导致备份失败，或者备份数据不可用。

参数：

创建备份用户：create user rep1 with sysadmin identified by ‘gauss@123’;
默认xlog复制使用stream方式复制，该方式最多占用2个max_wal_senders线程，需要确保该线程配置足够大.
select * from pg_stat_get_wal_senders();
show max_wal_senders;

创建测试数据
postgres=# create tablespace tbs1 location ‘/gauss/data/tbs1’; ## 创建绝对路径的表空间
postgres=# create table bak_test(name varchar(20)) tablespace tbs1;
postgres=# insert into bak_test values(‘This is a test’);
postgres=# select * from bak_test;

客户机备份操作:
使用tar格式压缩备份时，xlog模式不能使用stream，生成的tar包，需要用gs_tar命令解压
gs_basebackup -D /home/omm/gs_bak -X fetch -F t -z -h 192.168.0.225 -p 26000 -U rep1 -W

当有绝对路径表空间时，备份操作建议重新定位表空间，或者在远程客户端操作，否则有冲突
gs_basebackup -D /home/omm/gs_bak -T /gauss/data/tbs1=/home/omm/gs_bak/tbs1 -h 192.168.0.225 -p 26000 -U rep1 -W

普通备份操作示例：
gs_basebackup -D /home/omm/gs_bak -h 192.168.0.225 -p 26000 -U rep1 -W

gs_basebackup恢复：

gs_basebackup备份的是数据库的二进制文件，因此在恢复时可以直接拷贝替换原有的文件，或者直接在备份的库上启动数据库。暂不支持备份文件增量恢复,恢复后需要检查数据库中的链接文件是否链接到正确的文件。
但需要注意的是，必要时需要在实例启动前先修改配置参数(如：服务端口，主备复制配置等信息)。

若要在原库的地方恢复数据库，参考步骤如下：
关闭数据库–>备份已有数据库–>清理已有数据文件–>恢复目标数据文件–>按需创建软链接–>调整参数启动目标数据库

客户机恢复实例：
备份原数据库目录
cd /gauss
mv data data_bak
mkdir -p data/db1

恢复base.tar至/gauss/data/db1
cd /home/omm/bak/
gunzip *.gz
gs_tar -D /gauss/data/db1 -F base.tar ## tar包需要用gs_tar命令解压备份至指定目录

检查表空间映射信息
[omm@db2 db1]$ cd /gauss/data/db1
[omm@db2 db1]$ cat tablespace_map
16434 /gauss/data/tbs2
16386 /gauss/data/db1/pg_location/tablespace/tbs1

解压表空间备份至指定目录
mkdir -p /gauss/data/tbs2
mkdir -p /gauss/data/db1/pg_location/tablespace/tbs1
cd /home/omm/bak/
gs_tar -D /gauss/data/tbs2 -F 16434.tar
gs_tar -D /gauss/data/db1/pg_location/tablespace/tbs1 -F 16386.tar

修改postgres.conf文件
[omm@client ~]$ cd /gauss/data/db1/
[omm@client db1]$ vi postgresql.conf

修改：
listen_addresses = ‘192.168.0.226’
local_bind_address = ‘192.168.0.226’
port = 27000
修改或删除复制链接
replconninfo1 = ‘localhost=192.168.100.11 localport=26001 localheartbeatport=26005 localservice=26004 remotehost=192.168.100.12 remoteport=26001 remoteheartbeatport=26005 remoteservice=26004’

启动备份数据库
[omm@client db1]$ gs_ctl start -D /gauss/data/db1/

检查恢复后的数据库状态
gsql -d mydb -p 27000 -r
select * from bak_test;

gs_probackup工具

gs_probackup工具可以对opengauss实例进行定期备份，以便在数据库出现故障时能够恢复服务器。
特点：
可用于备份单机数据库或者集群主节点数据库，为物理备份。
可备份外部目录的内容，如脚本文件、配置文件、日志文件、dump文件等。
支持增量备份、定期备份和远程备份。
可设置备份的留存策略、
若要采用ptrack增量备份，需要在postgresql.conf文件中添加enable_cbm_tracking=on。

限制：
备份必须由运行数据库服务器的用户执行。
备份和恢复的数据库服务器的主版本号必须相同。
如果要通过SSH在远程模式下备份数据库，需要在本地和远程安装相同主版本的数据库，并通过ssh-copy-id remote_user@remost_host命令设置本地主机备份用户和远程主机数据库用户的免密码ssh连接。
远程模式下只能执行add-instance、backup、restore子命令。
使用restore子命令前，应先停止gaussdb进程。

支持full全备份和ptrack增量备份两种模式
gs_probackup backup --help|grep backup-mode
gs_probackup backup -B backup-path --instance=instance_name -b backup-mode
-b,–backup-mode=backup-mod backup mode=full|ptrack
注意：
1.如果实例做过恢复，需要重新做一次full全备，才能接着使用增量备份.
2.gs_probackup backup使用external-dirs选项，gs_probackup restore使用external-mapping选项，不要混淆。
3.gs_probackup restore需要同时使用external-dirs和external-mapping选项。
4.多个表空间选项可以使用多次，选项里面等号前后分别映射备份和恢复的表空间路径。

gs_probackup对gs_basebackup的增强：
支持ptrack增量备份；
支持增量恢复：基于页级增量恢复；
merge合并：合并增量备份；
数据备份有效性自动检测，无需实际的数据恢复；
数据库实例checksun检测（需要打开checksum）;
备份保留策略：按时间或数量保留wal归档及备份;
多线程并行化：支持backup、restore、merge等;
支持远程操作:支持ssh方式远程备份或恢复实例；
支持从standby备份，避免主库额外负载压力；
数据存储在外部目录：于pgdata保持独立；
备份元数据管理：命令配置持久化到文件；

gs_backup工具

gs_backup工具可以帮助用户备份和恢复openGauss数据库二进制程序和参数文件等。前提条件：
可以正常连接openGauss数据库；
需以操作系统用户omm执行gs_backup命令；
gs_backup命令备份的是openGauss数据库二进制程序和参数文件，并非备份数据；
如果没有使用-h参数指定节点，则备份时会备份到所有节点的备份目录中，恢复时也会从所有节点的备份目录中读取备份文件。
参数：

使用gs_backup脚本备份openGauss主机的二进制程序和参数文件
gs_backup -t backup --backup-dir=/home/omm/backup --all -l /home/omm/backup/log20200818.log

使用gs_backup脚本恢复主/备节点openGauss的二进制程序和参数文件
恢复前请先确保恢复目标目录存在cluster_static_config文件
[omm@db1 gauss]$ mkdir -p /gauss/app_0bd0ce80/bin/
[omm@db1 gauss]$ cp /home/omm/backup/app_0bd0ce80/bin/cluster_static_config /gauss/app_0bd0ce80/bin/
[omm@db1 gauss]$ ln -s app_0bd0ce80 app

[omm@db1 gauss]$ gs_backup -t restore --backup-dir=/home/omm/backup/   --all
Parsing configuration files.
Successfully parsed the configuration file.
Performing remote restoration.
Successfully restored cluster files.

PITR(Point-In-Time Recovery，简称PITR)
opengauss的即时恢复功能，可以支持恢复到备份归档数据之后的任意时间点。

recovery.conf文件配置

归档恢复配置
restore_command = ‘cp /mnt/server/archivedir/%f %p’ ## 获取所需的WAL文件。
archive_cleanup_command = ‘pg_archivecleanup /mnt/server/archivedir %r’ ## 清理PITR恢复不需要的WAL归档日志
recovery_end_command = string ## (可选) 在恢复完成时执行的SHELL命令

说明：
%f即归档检索中的文件名，%p即复制目的地的路径名，%r最新可用重启点的文件名
如果多个备机从相同的归档路径恢复时，需要确保该路径存在所有备机恢复所需要的WAL文件。

恢复目标设置(四选一)
recovery_target_name = ‘restore_point_1’ ## 还原到一个使用pg_create_restore_point()创建的还原点
recovery_target_time = ‘2020-01-01 12:00:00’ ## 还原到一个指定时间戳
recovery_target_xid = ‘3000’ ## 还原到一个事务ID。
recovery_target_lsn = ‘0/0FFFFFF’ ## 还原到日志的指定LSN点。
recovery_target_inclusive = true
声明是否在指定恢复目标之后停止(true) 或 之前停止(false)。该声明仅支持恢复目标为recovery_target_time，recovery_target_xid和recovery_target_lsn的配置。

注意：如果不配置任何恢复目标 或 配置目标不存在，则默认恢复到最新的WAL日志点。

PITR恢复实例
创建测试数据
postgres=# select pg_current_xlog_location();
postgres=# create table t2(name varchar(20));
postgres=# insert into t2 values(‘This is 0/4A0003D0’);
postgres=# select pg_switch_xlog();
postgres=# select pg_switch_xlog();
postgres=# select pg_current_xlog_location();

postgres=# create table t3(name varchar(20));
postgres=# insert into t3 values(‘This is 0/4C013458’);
postgres=# select pg_current_xlog_location();

postgres=# select pg_switch_xlog();
postgres=# select pg_switch_xlog();

– 备份客户端完成物理restore后，暂时不启动数据库

– 拷贝WAL日志至备机xlog日志(清空已有xlog文件),确保备机需要的所有WAL日志均已拷贝完成
[omm@client ~]$ scp 192.168.0.225:/gauss/data/db1/pg_xlog/00000001000000000000004{49,A,B,C,D,E} /home/omm/gs_xlog/
– 配置recovery.conf文件
[omm@client ~]$ cd /gauss/data/db1/
[omm@client db1]$ vi recovery.conf

restore_command = ‘cp /home/omm/gs_xlog/%f %p’
archive_cleanup_command = ‘pg_archivecleanup /gauss/data/db1/pg_xlog %r’
recovery_target_lsn = ‘0/4C013458’
recovery_target_inclusive = true

– 重启备份机测试数据
[omm@client dn_6001]$ gs_om -t start
[omm@client dn_6001]$ $ gsql -d postgres -p 26000 -U omm -r
postgres=# select * from t2;

postgres=# select * from t3;
ERROR: relation “t3” does not exist on dn_6001
LINE 1: select * from t3;
^
– 修改recovery_target，继续往前恢复
[omm@client db1]$ vi recovery.conf
修改：recovery_target_lsn = ‘0/4C0171E8’

– 重启恢复查看测试数据
[omm@client db1]$ gs_om -t start
[omm@client db1]$ gsql -d postgres -p 26000 -U omm -r
postgres=# select * from t3;

– 查询数据库恢复状态
注意：此时openGauss处于recover状态，只读。
postgres=# create table t10(id int);
ERROR: cannot execute CREATE TABLE in a read-only transaction
postgres=# select pg_is_in_recovery();
postgres=# select pg_last_xlog_replay_location();

postgres=# select pg_last_xact_replay_timestamp();

– 结束恢复，机器对外提供服务
postgres=# select pg_xlog_replay_resume();
postgres=# select pg_is_in_recovery();

整理自：modb.pro/doc/7507
modb.pro/doc/25138