恢復PostgreSQL數據庫備份至GuassDB 200

gs_restore是GaussDB 200提供的與gs_dump配套的導入工具。經過該工具，可將gs_dump導出的文件導入至數據庫。這裏經過postgreSQL的pg_dump命令備份數據庫，而後經過gs_restore將其恢復到GuassDB 200中。

一、備份PostgreSQL

[postgres@oln ~]$ pg_dump -Fc -C rhnschema >/var/satellite/bak/pg_rhnschema.dump

二、GuassDB建立對應數據庫以及用戶

[omm@hd06 ~]$ gsql -d rhnschema -p 25308
gsql ((GaussDB Kernel V300R002C00 build 8a9c1eb6) compiled at 2019-08-01 18:47:38 commit 6093 last mr 10175 )
Non-SSL connection (SSL connection is recommended when requiring high-security)
Type "help" for help.

rhnschema=# CREATE DATABASE rhnschema WITH TEMPLATE = template0 ENCODING = 'UTF8' LC_COLLATE = 'en_US.UTF-8' LC_CTYPE = 'en_US.UTF-8';
rhnschema=# create role spwuser with sysadmin createdb password 'abcABC12';
rhnschema=# alter database rhnschema owner to spwuser;

三、執行gs_restore進行恢復

[omm@hd06 ~]$ gs_restore -j 4 -p 25308 -d rhnschema /tmp/pg_rhnschema.dmp

-j--表明同時運行多個進程，這個裏爲4個；
-p--表明GuassDB端口號，默認爲25308；
-d--鏈接數據庫的dbname，並直接將數據導入到該數據庫中。

四、查看數據傾斜狀態

GaussDB 200是採用Shared-nothing架構的MPP（Massive Parallel Processor，大規模併發處理）系統，採用水平分佈的方式，將業務數據表的元組按合適的分佈策略分散存儲在全部的DN。

當前產品支持複製（Replication）和散列（Hash）兩種用戶表分佈策略。

• Replication方式：在每個DN上存儲一份全量表數據。對於數據量比較小的表建議採起Replication分佈策略。
• Hash方式：採用這種分佈方式，須要爲用戶表指定一個分佈列（distribute key）。當插入一條記錄時，系統會根據分佈列的值進行hash運算後，將數據存儲在對應的DN中。對於數據量比較大的表建議採起Hash分佈策略。

對於Hash分佈策略，若是分佈列選擇不當，可能致使數據傾斜。所以在採用Hash分佈策略以後會對用戶表的數據進行數據傾斜性檢查，以確保數據在各個DN上是均勻分佈的。通常狀況下分佈列都是選擇鍵值重複度小，數據分佈比較均勻的列。

• 確認集羣環境中的DN數

  rhnschema=# SELECT count(*) FROM pgxc_node where node_type='D';

• 查看錶的數據傾斜性
  如下查詢兩張較大表的數據傾斜性。

  rhnschema=# SELECT a.count,b.node_name FROM (SELECT count(*) AS count,xc_node_id FROM rhnchecksum GROUP BY xc_node_id) a, pgxc_node b WHERE a.xc_node_id=b.node_id ORDER BY a.count desc;

  
  
  根據查詢結果得知，各DN上數據分佈差小於10%，數據分佈均衡。若各DN上數據分佈差大於等於10%，代表數據分佈傾斜，須要刪除目標表，而後從新導入。

  補錄：GaussDB數據庫遷移

  這裏演示將GaussDB單機版的數據遷移到集羣環境中。

• 使用gs_dump備份單機版數據庫

  [omm@hd06 ~]$ gs_dump -f /srv/BigData/mppdb/data1/rhnschema.dmp -p 25308 rhnschema -F c -C
  gs_dump[port='25308'][rhnschema][2019-10-25 17:07:03]: The total objects number is 3889.
  gs_dump[port='25308'][rhnschema][2019-10-25 17:07:11]: [100.00%] 3889 objects have been dumped.
  gs_dump[port='25308'][rhnschema][2019-10-25 17:22:19]: dump database rhnschema successfully
  gs_dump[port='25308'][rhnschema][2019-10-25 17:22:19]: total time: 919737  ms
  [omm@hd06 ~]$ la /srv/BigData/mppdb/data1/rhnschema.dmp
  -rw------- 1 omm wheel 2.8G Oct 25 17:22 /srv/BigData/mppdb/data1/rhnschema.dmp

  備份完成後，將備份文件拷貝到集羣環境任意一個節點上：

  [omm@hd06 ~]$ scp /srv/BigData/mppdb/data1/rhnschema.dmp hd01:/srv/BigData/mppdb/data1/

• 使用gs_restore恢復數據庫
  恢復以前，先建立對應的數據庫以及用戶。

[omm@hd01 ~]$ gsql -p 25308 postgres
gsql ((GaussDB Kernel V300R002C00 build 8a9c1eb6) compiled at 2019-08-01 18:47:38 commit 6093 last mr 10175 )
Non-SSL connection (SSL connection is recommended when requiring high-security)
Type "help" for help.

postgres=# CREATE DATABASE rhnschema WITH TEMPLATE = template0 ENCODING = 'UTF8' LC_COLLATE = 'en_US.UTF-8' LC_CTYPE = 'en_US.UTF-8';
CREATE DATABASE
postgres=# create role spwuser with sysadmin createdb password 'abcABC12';
CREATE ROLE
postgres=# alter database rhnschema owner to spwuser;
ALTER DATABASE

恢復過程以下：

[omm@hd01 ~]$ gs_restore -p 25308 -j 8 -d rhnschema /srv/BigData/mppdb/data1/rhnschema.dmp 
restore operation successful
total time: 921733  ms