gs_restore是GaussDB 200提供的与gs_dump配套的导入工具。通过该工具,可将gs_dump导出的文件导入至数据库。这里通过postgreSQL的pg_dump命令备份数据库,然后通过gs_restore将其恢复到GuassDB 200中。

1、备份PostgreSQL

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

2、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;

3、执行gs_restore进行恢复

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

-j--代表同时运行多个进程,这个里为4个;
-p--代表GuassDB端口号,默认为25308;
-d--连接数据库的dbname,并直接将数据导入到该数据库中。

4、查看数据倾斜状态

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';

    恢复PostgreSQL数据库备份至GuassDB 200

  • 查看表的数据倾斜性
    以下查询两张较大表的数据倾斜性。
    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;

    恢复PostgreSQL数据库备份至GuassDB 200
    恢复PostgreSQL数据库备份至GuassDB 200
    根据查询结果得知,各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