openGauss数据库逻辑备份与恢复
简介
之前的数据库迁移系列中，是将其他类型的数据库数据迁移到openGauss中。实际使用中，还存在不同的openGauss数据库之间的迁移或者数据的备份。数据在同类型数据库迁移或者数据备份时，需要进行数据导出导入。openGauss提供了gs_dump工具导出指定数据，gs_restore工具将其恢复到数据库中。工具在安装包中已经携带，不需要额外安装。
文章目录
- 简介
- 工具说明
-
- gs_dump
- gs_dumpall
- gs_restore
- 使用示例
-
- 准备环境和数据
- gs_dump导出
- gs_dumpall导出
- gs_restore导入
工具说明
gs_dump
gs_dump是openGauss用于导出数据库相关信息的工具，用户可以自定义导出一个数据库或其中的对象（模式、表、视图等），回收站对象除外。支持导出的数据库可以是默认数据库postgres，也可以是自定义数据库。gs_dump工具在进行数据导出时，其他用户可以访问openGauss数据库（读或写），支持导出完整一致的数据。pg_dump只备份数据库集群中的某个数据库的数据，它不会导出角色和表空间相关的信息，因为这些信息是整个数据库集群共用的，不属于某个单独的数据库。
gs_dump支持将数据库信息导出至纯文本格式的SQL脚本文件或其他归档文件中。还可以用于openGauss与PostgreSQL之间的迁移。
gs_dumpall
gs_dumpall是openGauss用于导出所有数据库相关信息工具，导出特点和gs_dump非常相似，导出openGauss数据库的所有数据，包括默认数据库postgres的数据、自定义数据库的数据以及openGauss所有数据库公共的全局对象。gs_dumpall在导出openGauss所有数据库时分为两部分：
- gs_dumpall自身对所有数据库公共的全局对象进行导出，包括有关数据库用户和组、表空间以及属性（例如，适用于数据库整体的访问权限）信息。
- gs_dumpall通过调用gs_dump来完成openGauss中各数据库的SQL脚本文件导出，该脚本文件包含将数据库恢复为其保存时的状态所需要的全部SQL语句。
以上两部分导出的结果为纯文本格式的SQL脚本文件，使用gsql运行该脚本文件可以恢复openGauss数据库。
gs_restore
gs_restore是openGauss提供的针对gs_dump导出数据的导入工具。通过此工具可将由gs_dump生成的导出文件进行导入。主要功能包含：
导入到数据库：如果连接参数中指定了数据库，则数据将被导入到指定的数据库中。其中，并行导入必须指定连接的密码。导入时生成列会自动更新，并像普通列一样保存。
导入到脚本文件：如果未指定导入数据库，则创建包含重建数据库所必须的SQL语句脚本并写入到文件或者标准输出。等效于直接使用gs_dump导出为纯文本格式。
使用示例
注意：gs_dump和gs_restore工具需要由操作系统用户omm执行。
准备环境和数据
环境：CentOS 7.6 + openGauss 3.1.0 极简版
建用户和数据库
[omm@pekphisprb70593 ~]$ gsql -d postgres
CREATE USER dumpuser identified by 'Gauss_234';
GRANT ALL PRIVILEGES TO dumpuser ;
CREATE DATABASE dumpdb with owner dumpuser ENCODING 'utf8' template = template0;
建表
create table test1 (id integer,name varchar(20),salary float,time date,addr varchar(200),primary key(id)) ;
insert into test1 values (1,'zhangsan',2000.00,'2018-06-01 00:00:00','beijing');
insert into test1 values (2,'李四',2000.89,'2018-06-01 00:00:00','西安');
insert into test1 values (3,'Bob',2000,'2018-06-02 00:00:00','南京');
create table if not exists test2(id int primary key);
create table public.test3(id int primary key,name varchar(20));
insert into public.test3 values (1234567,'Kevin');
[omm@hecs-1105531 ~]$ cd /home/omm/
[omm@hecs-1105531 ~]$ mkdir dump
gs_dump导出
通用参数说明：
-f, –file=FILENAME
将输出发送至指定文件或目录。如果省略该参数，则使用标准输出。如果输出格式为（-F c/-F d/-F t）时，必须指定-f参数。如果-f的参数值含有目录，要求当前用户对该目录具有读写权限，并且不能指定已有目录。
-F, –format=c|d|t|p
选择输出格式。格式如下：
p|plain：输出一个文本SQL脚本文件（默认）。
c|custom：输出一个自定义格式的归档，并且以目录形式输出，作为gs_restore输入信息。该格式是最灵活的输出格式，因为能手动选择，而且能在恢复过程中将归档项重新排序。该格式默认状态下会被压缩。
d|directory：该格式会创建一个目录，该目录包含两类文件，一类是目录文件，另一类是每个表和blob对象对应的数据文件。
t|tar：输出一个tar格式的归档形式，作为gs_restore输入信息。tar格式与目录格式兼容；tar格式归档形式在提取过程中会生成一个有效的目录格式归档形式。但是，tar格式不支持压缩且对于单独表有8GB的大小限制。此外，表数据项的相应排序在恢复过程中不能更改。
输出一个tar格式的归档形式，也可以作为gsql输入信息。
-c, –clean
在将创建数据库对象的指令输出到备份文件之前，先将清理（删除）数据库对象的指令输出到备份文件中。（如果目标数据库中没有任何对象，gs_restore工具可能会输出一些提示性的错误信息）
该选项只对文本格式有意义。针对归档格式，可以调用gs_restore时指定选项。
-C, –create
备份文件以创建数据库和连接到创建的数据库的命令开始。（如果命令脚本是这种方式执行，可以先指定任意数据库用于执行创建数据库的命令，数据不会恢复到指定的数据库中，而是恢复到创建的数据库中。）
该选项只对文本格式有意义。针对归档格式，可以在调用gs_restore时指定选项。
-E, –encoding=ENCODING
以指定的字符集编码创建转储。默认情况下，以数据库编码创建转储。（得到相同结果的另一个办法是将环境变量“PGCLIENTENCODING”设置为所需的转储编码。）
-n, –schema=SCHEMA
只转储与模式名称匹配的模式，此选项包括模式本身和所有它包含的对象。如果该选项没有指定，所有在目标数据库中的非系统模式将会被转储。写入多个-n选项来选择多个模式。此外，根据gsql的\d命令所使用的相同规则，模式参数可被理解成一个pattern，所以多个模式也可以通过在该pattern中写入通配符来选择。使用通配符时，注意给pattern打引号，防止shell扩展通配符。
更多参数说明参考官网文档。
导出为文本格式：
执行gs_dump，导出dumpdb 数据库全量信息，导出的DUMPDB_backup.sql文件格式为纯文本格式。这种的可以编辑，但是不建议。
[omm@hecs-1105531 ~]$ gs_dump -U dumpuser -W Gauss_234 -f /home/omm/dump/DUMPDB_backup.sql -p 5432 dumpdb -F p
gs_dump[port='5432'][dumpdb][2022-12-07 15:25:09]: The total objects number is 439.
gs_dump[port='5432'][dumpdb][2022-12-07 15:25:09]: [100.00%] 439 objects have been dumped.
gs_dump[port='5432'][dumpdb][2022-12-07 15:25:09]: dump database dumpdb successfully
gs_dump[port='5432'][dumpdb][2022-12-07 15:25:09]: total time: 1493 ms
导出为归档格式
执行gs_dump，导出dumpdb数据库全量信息，导出的DUMPDB_backup.tar文件格式为tar格式。
[omm@hecs-1105531 dump]$ gs_dump -U dumpuser -W Gauss_234 -f /home/omm/dump/DUMPDB_backup.tar -p 5432 dumpdb -F t
gs_dump[port='5432'][dumpdb][2022-12-07 15:54:45]: The total objects number is 439.
gs_dump[port='5432'][dumpdb][2022-12-07 15:54:45]: [100.00%] 439 objects have been dumped.
gs_dump[port='5432'][dumpdb][2022-12-07 15:54:45]: dump database dumpdb successfully
gs_dump[port='5432'][dumpdb][2022-12-07 15:54:45]: total time: 1452 ms
执行gs_dump，导出dumpdb数据库全量信息，导出的DUMPDB_backup.dmp文件格式为自定义归档格式。
[omm@hecs-1105531 dump]$ gs_dump -U dumpuser -W Gauss_234 -f /home/omm/dump/DUMPDB_backup.dmp -p 5432 dumpdb -F c
gs_dump[port='5432'][dumpdb][2022-12-08 09:37:18]: The total objects number is 439.
gs_dump[port='5432'][dumpdb][2022-12-08 09:37:18]: [100.00%] 439 objects have been dumped.
gs_dump[port='5432'][dumpdb][2022-12-08 09:37:18]: dump database dumpdb successfully
gs_dump[port='5432'][dumpdb][2022-12-08 09:37:18]: total time: 1463 ms
导出指定schema下面的表
执行gs_dump，导出dumpdb数据库的表（或视图、或序列、或外表）对象，例如表test1。
[omm@hecs-1105531 dump]$ gs_dump -U dumpuser -W Gauss_234 -f /home/omm/dump/test1_bkp.sql -t public.test1 -p 5432 dumpdb
gs_dump[port='5432'][dumpdb][2022-12-07 16:01:28]: The total objects number is 423.
gs_dump[port='5432'][dumpdb][2022-12-07 16:01:28]: [100.00%] 423 objects have been dumped.
gs_dump[port='5432'][dumpdb][2022-12-07 16:01:28]: dump database dumpdb successfully
gs_dump[port='5432'][dumpdb][2022-12-07 16:01:28]: total time: 1024 ms
gs_dumpall导出
使用gs_dumpall一次导出openGauss的所有数据库
[omm@hecs-1105531 dump]$ gs_dumpall -f /home/omm/dump/bkpall.sql -p 5432
gs_dump[port='5432'][dbname='dumpdb'][2022-12-07 16:12:17]: The total objects number is 439.
gs_dump[port='5432'][dbname='dumpdb'][2022-12-07 16:12:17]: [100.00%] 439 objects have been dumped.
gs_dump[port='5432'][dbname='dumpdb'][2022-12-07 16:12:17]: dump database dbname='dumpdb' successfully
gs_dump[port='5432'][dbname='dumpdb'][2022-12-07 16:12:17]: total time: 1243 ms
gs_dump[port='5432'][dbname='finance'][2022-12-07 16:12:18]: The total objects number is 459.
gs_dump[port='5432'][dbname='finance'][2022-12-07 16:12:19]: [100.00%] 459 objects have been dumped.
gs_dump[port='5432'][dbname='finance'][2022-12-07 16:12:19]: dump database dbname='finance' successfully
gs_dump[port='5432'][dbname='finance'][2022-12-07 16:12:19]: total time: 1798 ms
gs_dump[port='5432'][dbname='mydb'][2022-12-07 16:12:20]: The total objects number is 621.
gs_dump[port='5432'][dbname='mydb'][2022-12-07 16:12:20]: [100.00%] 621 objects have been dumped.
gs_dump[port='5432'][dbname='mydb'][2022-12-07 16:12:20]: dump database dbname='mydb' successfully
gs_dump[port='5432'][dbname='mydb'][2022-12-07 16:12:20]: total time: 1905 ms
gs_dump[port='5432'][dbname='newdb'][2022-12-07 16:12:22]: The total objects number is 432.
gs_dump[port='5432'][dbname='newdb'][2022-12-07 16:12:22]: [100.00%] 432 objects have been dumped.
gs_dump[port='5432'][dbname='newdb'][2022-12-07 16:12:23]: dump database dbname='newdb' successfully
gs_dump[port='5432'][dbname='newdb'][2022-12-07 16:12:23]: total time: 2070 ms
gs_dump[port='5432'][dbname='opengauss_db'][2022-12-07 16:12:25]: The total objects number is 611.
gs_dump[port='5432'][dbname='opengauss_db'][2022-12-07 16:12:25]: [100.00%] 611 objects have been dumped.
gs_dump[port='5432'][dbname='opengauss_db'][2022-12-07 16:12:25]: dump database dbname='opengauss_db' successfully
gs_dump[port='5432'][dbname='opengauss_db'][2022-12-07 16:12:25]: total time: 2529 ms
gs_dump[port='5432'][dbname='postgres'][2022-12-07 16:12:27]: The total objects number is 430.
gs_dump[port='5432'][dbname='postgres'][2022-12-07 16:12:27]: [100.00%] 430 objects have been dumped.
gs_dump[port='5432'][dbname='postgres'][2022-12-07 16:12:27]: dump database dbname='postgres' successfully
gs_dump[port='5432'][dbname='postgres'][2022-12-07 16:12:27]: total time: 1576 ms
gs_dump[port='5432'][dbname='school'][2022-12-07 16:12:29]: The total objects number is 449.
gs_dump[port='5432'][dbname='school'][2022-12-07 16:12:29]: [100.00%] 449 objects have been dumped.
gs_dump[port='5432'][dbname='school'][2022-12-07 16:12:29]: dump database dbname='school' successfully
gs_dump[port='5432'][dbname='school'][2022-12-07 16:12:29]: total time: 1933 ms
gs_dumpall[port='5432'][2022-12-07 16:12:29]: dumpall operation successful
gs_dumpall[port='5432'][2022-12-07 16:12:29]: total time: 13342 ms
[omm@hecs-1105531 dump]$ ll bkpall.sql
-rw------- 1 omm dbgrp 183028 Dec 7 16:12 bkpall.sql
gs_restore导入
工具通用参数：
-d, –dbname=NAME
连接数据库dbname并直接导入到该数据库中。
-a, –data-only
只导入数据，不导入模式（数据定义）。gs_restore的导入是以追加方式进行的。
-c, –clean
在重新创建数据库对象前，清理（删除）已存在于将要还原的数据库中的数据库对象。
-C, –create
导入到数据库之前会先使用CREATE DATABASE创建数据库（指定该选项后，-d指定的数据库仅用以执行CREATE DATABASE命令，所有数据将被导入到创建的数据库中）。
-e, –exit-on-error
当发送SQL语句到数据库时如果出现错误，请退出。默认状态下会继续，且在导入后会显示一系列错误信息。
更多参数说明参考官网文档。
下面我们将之前导出的备份文件进行导入。
在此之前，对于导出的单个数据库，需要新建一个空的数据库进行恢复。
[omm@hecs-1105531 dump]$ gsql -d postgres
openGauss=# create database new_dmpdb1;
openGauss=# create database new_dmpdb2;
openGauss=# create database new_dmpdb3;
openGauss=# \q
执行gs_restore，将导出的DUMPDB_backup.tar文件（tar格式）导入到new_dmpdb2数据库。
成功时显示如下：
[omm@hecs-1105531 dump]$ gs_restore /home/omm/dump/DUMPDB_backup.tar -p 5432 -d new_dmpdb2;
start restore operation ...
table test1 complete data imported !
table test2 complete data imported !
table test3 complete data imported !
Finish reading 15 SQL statements!
end restore operation ...
restore operation successful
total time: 37 ms
恢复指定表数据
执行gs_restore，使用自定义归档格式的DUMPDB_backup.dmp文件来导入PUBLIC模式下表test1。
成功时显示如下：
[omm@hecs-1105531 dump]$ gs_restore /home/omm/dump/DUMPDB_backup.dmp -p 5432 -d new_dmpdb1 -n public -t test1
start restore operation ...
table test1 complete data imported !
Finish reading 15 SQL statements!
end restore operation ...
restore operation successful
total time: 12 ms
注意，gs_restore默认是以追加的方式进行数据导入。为避免多次导入造成数据异常，在进行导入时，建议使用“-c” 参数，在重新创建数据库对象前，清理（删除）已存在于将要还原的数据库中的数据库对象。
使用gsql 导入纯文本格式
gsql是openGauss提供在命令行下运行的数据库连接工具，可以通过此工具连接服务器并对其进行操作和维护，除了具备操作数据库的基本功能，gsql还提供了若干高级特性，便于用户使用。这里我们使用他的“执行SQL语句”能力完成导入。
执行gsql ，使用纯文本格式DUMPDB_backup.sql文件来导入dumpdb 下全部信息。执行信息如下：
[omm@hecs-1105531 dump]$ gsql -d new_dmpdb3 -U dumpuser -f /home/omm/dump/DUMPDB_backup.sql
Password for user dumpuser:根据提示输入密码
查看结果
实验结束。
需要注意的是，逻辑备份只能基于备份时刻进行数据转储，所以恢复时也只能恢复到备份时保存的数据。例如，T1时刻启动gs_dump导出A数据库，那么导出数据结果将会是T1时刻A数据库的数据状态，T1时刻之后对A数据库的修改不会被导出。所以建议在业务空闲期间操作。对于故障点和备份点之间的数据，逻辑备份无能为力，逻辑备份适合备份那些很少变化的数据。如果通过逻辑备份进行全库恢复，通常需要重建数据库，导入备份数据来完成，恢复时间较长，通常不被采用，而使用物理备份恢复。由于逻辑备份具有平台无关性，所以更为常见的是逻辑备份被作为一个数据迁移及移动的主要手段。
如果您觉得博主的文章还不错或者有帮助的话，请关注一下博主，如果三连点赞评论收藏就更好啦！谢谢各位大佬给予的支持！