最近做了一次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.权限的迁移;

    权限的迁移,则要简单的多了,可以照迁移过来就可以了。感觉这个是迁移过程中除了函数之外,迁移最简单的一个了。