greenplum数据迁移记录，
最近做了一次greenplum的数据迁移，迁移途中也是到一些问题，在此来总结一下。
迁移场景：源集群1台master，4台segment, 16个primary数据库实例；迁移到的目标集群: 1台master, 6台segment, 36个primary实例，迁移完后，还会把前期的4仓库segment也补充到老集群中。
迁移数据量： 10TB
源集群: 5台服务器，master: 1 segment:4 instance: 16
最大单表容量：900GB
最大单表记录数：45亿条
要求：1天内迁移完成
greenplum version: 4.3.8
目标集群：7台服务器, master: 1 segment: 6 instance: 36
greenplum version: 4.3.16
1. 迁移方案的测试;
迁移方案一：在相同的greenplum版本下(greenplum4.3.8)使用gp_dump或者是gpcrondump在源集群上备份数据库，然后把备份集迁移到目标集群中进行恢复；
方案测试结论：不可行
原因如下：
(1) 备份时间太长，使用gpcrondump备份时长达到8个小时，而使用gp_dump，速度快了一些，也达到6个小时；
(2) master磁盘空间太小，需要多次恢复，由于备份数据量比较大，把文件从集群中拷贝到目标的集群中，需要的时间也是相当长的;
(3) 恢复速度不稳定，使用psql dbname -f back_xxxx_20170901XXXX进行恢复时，开始时，1个200GB的备份文件在1个小时内能恢复完成，但是越到后来，恢复时间越长，而且文件越大，恢复时间越长，记得有一个400GB的文件，恢复时间长达7个小时；
(4) 版本bug， 在恢复过程中，其实是使用copy xxxx from stdin; 语句进行恢复的，但是在恢复过程中，出现线程假死的状态，即，copy进程hang住，不出错误，也没返回结果，一起在执行，但是就是执行不完。
综上所述，使用gp_dump来迁移数据，已经是不可行的方案，后来copy的问题通过把集群的目标集群升级到greenplum4.3.16进行解决。但是想在一天内完成恢复，而且还有增量恢复，根本无法完成。
迁移方案二：gptransfer按schema进行恢复
由于网上可查的gptransfer方案相对来说比较少，所以也是自己慢慢摸索着尝试，先尝试着恢复单表，然后才是多表，最后才是schema。
gptransfer技术原理：其实是在源集群上通过gpfdist的并行技术直接向目标集群中写数据，所以速度相对来说会比较快。
在进行多轮测试后，方案可行，原因如下：
(1) 整个恢复过程不需要进行备份，拷贝再恢复的过程，而是直接通过网络复制，所以少了不少时间，经过测试，4TB的数据，最快大概在6个小时内完成;
(2) 整个恢复过程，日志中有基本的报告 ，写好脚本好，可以不用人为干预， 这一点比备份后进行恢复要好一些，通过日志就可以直观的看到你目前恢复到那一张表了;
(3) 恢复脚本简单，恢复过程也比较简单。而且恢复完成后，系统可能自验证。
缺点如下：
(1)不能增量恢复，对于昨天有过变更的数据表，不能直接进行增量恢复，特别是大表，恢复大表时，速度也是毕竟慢的，这个时候，重新恢复一次大表，代价太大，不如把增量数据copy出来，直接导出来得快。
(2) 恢复过程中，会出现某些表恢复失败的问题，而且通常出现在大表的恢复上，这个问题到，在网上有人说，是因为使用了udp协议导致的，参数如下：
gp_interconnect_type=udpifc ==》gp_interconnect_type=tcp
网上查到的资料，需要把协议改成tcp，果断修改后，确实比较以前好多了，但是仍然还是会出现恢复失败的问题。只能重新恢复。
注意：记得恢复完成后，把gp_interconnect_type参数还是修改为udp，因为不修改，对于查询的同事来说，绝对是个杯俱，自己有机会体验一下就好。
2.迁移过程中遇到的问题处理及方案如何处理
(1) 最大的问题，就是在验证迁移方案的过程，非常耗时，因为选择恢复的数据量太小，你根本不会发现问题，结果真正恢复时才发现问题，就真的悲催了，但是如果选择的数据量太大，又非常耗时，我在本次的迁移方案验证中，测试时选择的是25%的数据量进行恢复测试。
(2) 是否要升级的问题，我的意见是，能升级就升级，但是前提是要稳定版本。
(3) 有问题，时常在群里问一下前辈，总有人会遇到过你没遇到的问题，也解决过。
3.函数的迁移;
这个总体来说比较迁移，就是简单的导入导出就可以，最后分配一下owner;
4.序列的迁移;
序列的迁移对greenplum来说，是最郁闷的，因为你把一个database或者一个schema的所有数据字典导出来后，再导入后，你会发现，序列的起始值还永远是1，导出的是初始时定义的样子，但是现在的样子是已经分配过n个值的样子，所以所有的序列，你重新导入后，不仅要考虑到owner的问题，还需要重新把START值重新修改为与源集群的START值一致。
5.权限的迁移;
权限的迁移，则要简单的多了，可以照迁移过来就可以了。感觉这个是迁移过程中除了函数之外，迁移最简单的一个了。