恢复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