簡介

之前的數據庫遷移系列中，是將其他類型的數據庫數據遷移到openGauss中。實際使用中，還存在不同的openGauss數據庫之間的遷移或者數據的備份。數據在同類型數據庫遷移或者數據備份時，需要進行數據導出導入。openGauss提供了gs_dump工具導出指定數據，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數據庫的修改不會被導出。所以建議在業務空閑期間操作。對于故障點和備份點之間的數據，邏輯備份無能為力，邏輯備份適合備份那些很少變化的數據。如果通過邏輯備份進行全庫恢復，通常需要重建數據庫，導入備份數據來完成，恢復時間較長，通常不被采用，而使用物理備份恢復。由于邏輯備份具有平臺無關性，所以更為常見的是邏輯備份被作為一個數據遷移及移動的主要手段。

??如果您覺得博主的文章還不錯或者有幫助的話，請關注一下博主，如果三連點贊評論收藏就更好啦！謝謝各位大佬給予的支持！