最近迁移了一套gp环境，数据大概在32TB左右，所以做一下简单的记录。
OS Version: CentOS release 6.10 (Final)
GP Version: Greenplum Database 4.3.32.0 build 1
PC节点 ：８
迁移数据：32TB
过程： 由于数据库属于线上数据仓库，而迁移后的节点 和迁移前的节点数据量一致，所以选择使用gp_dump备份，gp_dump恢复的方式进行迁移。 整个迁移过程分2天完成。
第1天： 迁移数据没有变化的4TB，涉及到8个schema;
第2天： 迁移数据会产生变化的28TB，涉及到3个schema。
迁移数据时间： 第一天： 6小时， 第2天： 13小时， 一共19小时。连同迁移完成后的数据检查，大概花费将近30个小时左右。
只是不同的任务是不同的人完成的，比如环境搭建，并不是我完成的。而是运维完成的。
由于是相同节点迁移，所以这次迁移选择了相对方便一点的gp_dump我gp_restore, 而由于当初始迁移时，进行过充分的测试，所以迁移过程中没有出现任何问题，一切都比较顺利。
反倒是在测试时，有几个点需要注意一下，由于是直接把备份文件写入到目标服务器对应的目录下，所以需要把目标节点的目录 挂载到源服务器下，最好在相同节网络之下，如果达不到，至少也要保证两套环境的网络传输速度。
(1) 安装环境时，一定需要保持源数据库和目标数据库的DBID分配所在的节点一致；
(2) 保证目标节点上的目录权限对于源节点是可写的；
(3) 使用gpadmin用户进行迁移；
(4) 迁移过程中，记录备份时每一个key节点的值和记录备份和恢复时间；
(5) 迁移过程中，记得备份后产生的文件权限和属主在新服务器上是需要重新修改的。
结语：如果greenplum的迁移前的节点和迁移后的节点不一致，目前还有什么方案可选择？
方案1： 先备份和迁移表结构，再迁移数据；
备份表结构：pg_dump
迁移数据：gptransfer, gpcopy(新特性), gpbackup;
方案2：先使用gp_dump, gp_restore进行迁移到相同节点之中，再进行数据节点的扩展gp_expand；
其中方案2的风险比较高。
