MogDB物理备份恢复之自定义表空间

原作者：陆凯

• 1. 概述
• 2. 环境准备
• 3. gs_probackup工具介绍
• 4. 实践测试
• 5. 总结

1. 概述

在MogDB中，比较常用的物理备份工具是gs_basebackup和gs_probackup，后者的功能相对更加完善一些。本文主要测试如何在有自定义表空间存在的数据库进行物理备份与恢复以及需要注意的点。

2. 环境准备

• 系统：centos7
• 数据库版本：MogDB 5.0
• 架构：单机

3. gs_probackup工具介绍

参考连接：https://docs-opengauss.osinfra.cn/zh/docs/1.1.0/docs/Toolreference/gs_probackup.html#参数说明a-namezh-cn_topic_0287276008_section520716591338a

4. 实践测试

1.创建自定义表空间my_tablespace

postgres=# create tablespace my_tablespace location '/data/mog5';
CREATE TABLESPACE

2.在my_tablespace中新建测试表t

解释postgres=# create table t(id int) tablespace my_tablespace;
CREATE TABLE
postgres=# insert into t values(1),(2);
INSERT 0 2
postgres=# \d+ t
                                Table "public.t"
 Column |  Type   | Modifiers | Storage | Stats target | Description | Attalias 
--------+---------+-----------+---------+--------------+-------------+----------
 id     | integer |           | plain   |              |             | id
Has OIDs: no
Tablespace: "my_tablespace"
Options: orientation=row, compression=no, fillfactor=80

3.物理全备（不带参数-E）

gs_probackup init -B /backup/probackup/
gs_probackup add-instance -B /backup/probackup/ --instance=mogdb -D /database/mogdb/data
gs_probackup backup -B /backup/probackup/ --instance=mogdb -b full --delete-expired  

Tips：

• 备份操作需要在主库进行，且主库数据库服务正常运行（可连接）
• 当数据量比较大时，需调整参数wal_sender_timeout、session_timeout、–rw-timeout的值防止备份中途超时退出
• 适当调大wal_keep_segments的值确保需要的wal文件不被提前删除
• 如需增量备份，需要设置参数enable_cbm_tracking = on
• 当存在用户自定义表空间时，备份的时候要加上–external-dirs参数（-E，多个表空间用冒号分隔）

4.物理恢复
首先需要关闭数据库服务，移除当前数据目录，然后进行restore

gs_om -t stop
mv /database/mogdb/data /database/mogdb/data_bak
解释gs_probackup restore -B /backup/probackup/ --instance=mogdb -i xxx

LOG: Restore begin.
LOG: check tablespace directories of backup SAXVTP
ERROR: restore tablespace destination is not empty: "/data/mog5"

可以发现，当我们在使用gs_probackup进行物理备份时，如果不带自定义表空间相关参数，在恢复时仍然需要验证原先表空间目录为空，所以这里的判断就是一个很冗余的设计，因为如果确实没有将自定义表空间的数据进行备份（后面将会验证不带参数’-E’的情况下是否备份了数据），那么单纯地备份一个目录链接还会影响恢复操作，可以将该目录移除规避报错:

mv /data/mog5 /data/mog5_bak

5.启库验证

gs_ctl start -D $PGDATA
gsql -d postgres -p 17700 -r
解释postgres=# \dt
                               List of relations
 Schema | Name | Type  | Owner |                    Storage                     
--------+------+-------+-------+------------------------------------------------
 public | t    | table | omm   | {orientation=row,compression=no,fillfactor=80}
(1 row)
postgres=# select * from t;
ERROR:  could not open file "pg_tblspc/78372/PG_9.2_201611171_dn_6001/20538/78376": No such file or directory

上面证明了如果不带-E参数确实会导致自定义表空间的数据不被备份，但是会备份自定义表空间的目录名和相关的对象名，简单来说，全备不加-E参数时仍会备份自定义表空间的相关结构，但不含任何数据，当把/data/mog5_bak改回原来的/data/mog5后数据便可以正常抓到了。

解释postgres=# select * from t;
 id 
----
  1
  2
(2 rows)

6.备份自定义表空间

gs_probackup backup -B /backup/probackup/ --instance=mogdb -b full --delete-expired  -E /data/mog5

查看物理备份目录，多出的文件夹external_directories存储数据目录以外的数据（包括自定义表空间）：

解释-rw-------  1 omm dbgrp 1121926 Mar 26 14:08 backup_content.control
-rw-------  1 omm dbgrp     693 Mar 26 14:08 backup.control
drwx------ 27 omm dbgrp    4096 Mar 26 14:08 database
drwx------  3 omm dbgrp      26 Mar 26 14:07 external_directories
-rw-------  1 omm dbgrp 3281504 Mar 26 14:08 page_header_map

7.恢复验证
操作前需要先关库并移除当前数据目录，恢复操作同样会验证原本的自定义表空间目录为空（如果自定义表空间目录不为空脚本是不会直接把备份的数据放进去，防止覆盖等操作导致数据丢失）

mv /data/mog5 /data/mog5_bak
gs_probackup restore -B /backup/probackup/ --instance=mogdb -i xxx

当然，如果需要对自定义表空间替换目录位置可以使用–tablespace-mapping(-T)和–external-mapping来映射新目录，如果是单纯的外部目录只需要设定–external-mapping参数即可：

gs_probackup restore -B /backup/probackup/ --instance=mogdb -i xxx  --tablespace-mapping=/data/mog5=/data/mog5_new --external-mapping=/data/mog5=/data/mog5_new
解释postgres=# \db
          List of tablespaces
     Name      | Owner |    Location    
---------------+-------+----------------
 my_tablespace | omm   | /data/mog5_new
 pg_default    | omm   | 
 pg_global     | omm   |

5. 总结

当自定义表空间存在时，使用gs_probackup进行全备如果不加参数-E，并不会备份自定义表空间，但是会备份自定义表空间目录名（恢复时验证自定义表空间为空），所以往往需要加上-E参数，并在恢复时选择置空原自定义表空间目录还是重映射，从而实现自定义表空间的备份恢复。