使用gptransfer迁移数据

参考文档：

https://gpdb.docs.pivotal.io/43160/admin_guide/managing/gptransfer.html

https://my.oschina.net/goopand/blog/510083

最近在做greenplum数据仓库的迁移时，数据规模在10T左右。

集群一信息:

版本信息：greenplum4.3.8

master

sdw1

sdw2

sdw3

sdw4

目标集群：

版本信息：greenplum4.3.16.1

master

gdw1

gdw2

gdw3

gdw4

gdw5

gdw6

由于需要迁移到的目标集群的服务器和节点数与源集群的目标和节点数多，所以选择并行的恢复方案已经不可能，所以临时选择了gpcrondump方案：

方案一：gpcrondump方案:

进行全备后，发现备份在解压后的文件过大，而且备份时间过长，所以把暂时把gpcrondump方案去掉了,后续有时间还会进行测试；

方案二：gp_dump方案：

吸取了每一次的教训，对schema进行备份后，每次1-2个schema, 16个segment的实例，每个segment备份出来的数据文件大概在210GB左右。

恢复文件大小基本能接受，但是整个恢复过程比较 慢，因为需要把每一个备份文件都拷贝到目标集群中的master节点后，再进行恢复，一个对磁盘空间是考验，另一个，对备份文件的拷贝也是一个挑战，整个恢复过程，仅拷贝备份文件到目标集群的master节点所占时间就用了近10个小时。

最重要的一点，早先对数据进行恢复时，目标集群选择的也greenplum4.3.8版本，但是在恢复过程中，copy进程一直处于无反应状态，但是整个恢复过程在日志中也没有任何提示信息。后来在一些QQ群中和前辈交流后，果断换了最新的版本greenplum4.3.16.1，此问题才顺利解决。但是即使如此，感觉在恢复过程中，也会遇到一些莫名的问题，感觉有些奇怪。

不管是使用gp_dump还是gpcrondump备份后，都需要使用psql工具进行恢复，语法如下：

psql dbname -f /xxx/xxx/xxx.sql

方案三：

在进行上面的2种方案尝试后，又尝试了gpfdist方案和gptransfer方案，感觉还是gptransfer方案感觉比较好用一些，所以做一个简单的总结，

gptransfer定义可以为单独的表，数据库和文件进行数据的同步.

如下是对一个表进行gptransfer的传输

gptransfer -t iosta.madfid.xxx_ccccc_status_1503 --source-map-file=host_source -a --dest-host=10.159.xx.55 --dest-database=map --batch-size=2 --truncate >> gptranfer.log 

需要注意的以下问题:

最重要，把源集群和目标集群使用gpssh-exkeys打通。

(1) 先看你选择在源集群上还是在目标集群上传输数据，我选择的是在源集群上传输数据，所需要的参数会少一些:

(2) 如下内容为host_source文件的内容，记录的是源集群的主机信息，其中sdw1,sdw2,sdw3,sdw4为服务器的真实主机名。

  sdw1,172.168.2.1
  sdw2,172.168.2.2
  sdw3,172.168.2.3
  sdw4,172.168.2.4

(3) 目标集群中的master主机名;

(4) -a参数，最好带上，因为不带上，还会需要人做一次确认选择

(5) dest_databse 同步数据时，可以选择不同的数据库

(6) --batch-size，每次同步表的数量，就是可以同时同步多少张表的意思，如果你不写此参数，数据库会自动帮你设定

(7) --truncate 此选择，只有在目标集群中表中有数据时，带上才有意义，如果目标集群中还没有表，那么不带最好。