背景信息
gs_restore是openGauss提供的针对gs_dump导出数据的导入工具。通过此工具可将由gs_dump生成的导出文件进行导入。
gs_restore工具由操作系统用户omm执行。
主要功能包含：
- 导入到数据库
如果连接参数中指定了数据库，则数据将被导入到指定的数据库中。其中，并行导入必须指定连接的密码。导入时生成列会自动更新，并像普通列一样保存。
- 导入到脚本文件
如果未指定导入数据库，则创建包含重建数据库所必须的SQL语句脚本并写入到文件或者标准输出。等效于直接使用gs_dump导出为纯文本格式。
命令格式
gs_restore [OPTION]... FILE
说明：
- FILE没有短选项或长选项。用来指定归档文件所处的位置。
- 作为前提条件，需输入dbname或-l选项。不允许用户同时输入dbname和-l选项。
- gs_restore默认是以追加的方式进行数据导入。为避免多次导入造成数据异常，在进行导入时，建议使用“-c” 参数，在重新创建数据库对象前，清理（删除）已存在于将要还原的数据库中的数据库对象。
- 日志打印无开关，若需隐藏日志，请将日志重定向到日志文件。若恢复表数据时，数据量很大，会分批恢复，因此会多次出现“表数据已完成导入”的日志。
表 1 常用参数说明
参数 |
参数说明 |
举例 |
|---|---|---|
-U |
连接数据库的用户名。 |
-U jack |
-W |
指定用户连接的密码。
|
-W abcd@123 |
-d |
连接数据库dbname，并直接将数据导入到该数据库中。 |
-d backupdb |
-p |
指定服务器所侦听的TCP端口或本地Unix域套接字后缀，以确保连接。 |
-p 8000 |
-e |
当发送SQL语句到数据库时如果出现错误，则退出。默认状态下会忽略错误任务并继续执行导入，且在导入后会显示一系列错误信息。 |
- |
-c |
在重新创建数据库对象前，清理（删除）已存在于将要导入的数据库中的数据库对象。 |
- |
-s |
只导入模式定义，不导入数据。当前的序列值也不会被导入。 |
- |
示例
特例：执行gsql程序，使用如下选项导入由gs_dump/gs_dumpall生成导出文件夹（纯文本格式）的MPPDB_backup.sql文件到postgres数据库。
gsql -d postgres -p 15400 -W Bigdata@123 -f /home/omm/test/MPPDB_backup.sql SET SET SET SET SET ALTER TABLE ALTER TABLE ALTER TABLE ALTER TABLE ALTER TABLE CREATE INDEX CREATE INDEX CREATE INDEX SET CREATE INDEX REVOKE REVOKE GRANT GRANT total time: 30476 ms
gs_restore用来导入由gs_dump生成的导出文件。
示例1：执行gs_restore，将导出的MPPDB_backup.dmp文件（自定义归档格式）导入到postgres数据库。
gs_restore -W Bigdata@123 backup/MPPDB_backup.dmp -p 15400 -d postgres gs_restore: restore operation successful gs_restore: total time: 13053 ms
示例2：执行gs_restore，将导出的MPPDB_backup.tar文件（tar格式）导入到postgres数据库。
gs_restore backup/MPPDB_backup.tar -p 15400 -d postgres gs_restore[2017-07-21 19:16:26]: restore operation successful gs_restore[2017-07-21 19:16:26]: total time: 21203 ms
示例3：执行gs_restore，将导出的MPPDB_backup文件（目录格式）导入到postgres数据库。
gs_restore backup/MPPDB_backup -p 15400 -d postgres gs_restore[2017-07-21 19:16:26]: restore operation successful gs_restore[2017-07-21 19:16:26]: total time: 21003 ms
示例4：执行gs_restore，使用自定义归档格式的MPPDB_backup.dmp文件来进行如下导入操作。 导入PUBLIC模式下所有对象的定义和数据。在导入时会先删除已经存在的对象，如果原对象存在跨模式的依赖则需手工强制干预。
gs_restore backup/MPPDB_backup.dmp -p 15400 -d postgres -e -c -n PUBLIC
gs_restore: [archiver (db)] Error while PROCESSING TOC:
gs_restore: [archiver (db)] Error from TOC entry 313; 1259 337399 TABLE table1 gaussdba
gs_restore: [archiver (db)] could not execute query: ERROR: cannot drop table table1 because other objects depend on it
DETAIL: view t1.v1 depends on table table1
HINT: Use DROP ... CASCADE to drop the dependent objects too.
Command was: DROP TABLE public.table1;
手工删除依赖，导入完成后再重新创建。
gs_restore backup/MPPDB_backup.dmp -p 15400 -d postgres -e -c -n PUBLIC gs_restore[2017-07-21 19:16:26]: restore operation successful gs_restore[2017-07-21 19:16:26]: total time: 2203 ms
示例5：执行gs_restore，使用自定义归档格式的MPPDB_backup.dmp文件来进行如下导入操作。只导入PUBLIC模式下表table1的定义。
gs_restore backup/MPPDB_backup.dmp -p 15400 -d postgres -e -c -s -n PUBLIC -t table1 gs_restore[2017-07-21 19:16:26]: restore operation successful gs_restore[2017-07-21 19:16:26]: total time: 21000 ms
示例6：执行gs_restore，使用自定义归档格式的MPPDB_backup.dmp文件来进行如下导入操作。只导入PUBLIC模式下表table1的数据。
gs_restore backup/MPPDB_backup.dmp -p 15400 -d postgres -e -a -n PUBLIC -t table1 gs_restore[2017-07-21 19:16:26]: restore operation successful gs_restore[2017-07-21 19:16:26]: total time: 20203 ms
总结
到此这篇关于使用gs_restore导入数据的文章就介绍到这了,更多相关gs_restore导入数据内容请搜索脚本之家以前的文章或继续浏览下面的相关文章希望大家以后多多支持脚本之家！