Greenplum集群迁移与扩容实践

最新推荐文章于 2024-06-01 19:02:57 发布

hmxz1024

最新推荐文章于 2024-06-01 19:02:57 发布

阅读量1.5k

点赞数 1

分类专栏： GreenPlum 文章标签： greenplum 迁移扩容

本文链接：https://blog.csdn.net/hmxz2nn/article/details/89842839

版权

GreenPlum 专栏收录该内容

19 篇文章 6 订阅

订阅专栏

记录针对客户的集群迁移与扩容过程，针对该过程中的坑做一下总结。

场景描述

客户现场有3台装有greenplum的集群，目前数据量约1T左右，客户想再增加3台服务器到集群中。在此过程中，由于客户想进行机房的搬迁，而在此过程中不长时间中断业务的使用。所以就采用以下方案：
先在新的机房中安装并部署greenplum集群，然后将旧的集群中的数据迁移到新的集群中，先使用新的集群开展业务，待旧的主机搬迁到新的机房后进行扩容加入。

检查数据库状态

到客户现场后，在数据迁移前先检查旧的集群的状态，通过gpstate -e命令，发现集群中segment的一些instance有挂掉的状况，并因此导致了primary和mirror角色的错位。对于这种现象，使用gprecoverseg命令进行恢复，若恢复不成功，使用gprecoverseg -F进行全量恢复。在使用gprecoverseg命令进行恢复时，恢复失败，不得已进行了数据库的重启，又发现重启失败，通过查看gp_log目录下的startup.log，可以获得重启失败的原因。重启失败的原因是数据库中的一个参数修改的太大导致，这时，先在master节点上对该参数进行修改（在postgresql.conf文件里修改），然后通过gpstart -m命令重启mater节点，然后通过gpconfig命令修改其他节点的参数值，修改完成后重启数据库即可。
继续进行gprecoverseg -F进行全量恢复，在恢复过程中，通过gpstate -m查看镜像同步状态，发现在进行数据同步时，速度非常的慢，当时没有仔细去考虑该问题的原因，这位后续的数据迁移缓慢，埋下了伏笔。

集群数据迁移

使用gptransfer命令进行集群的迁移。
一个参考迁移命令是：

gptransfer -d test_db --source-map-file=host_source -a --dest-host=101.8.187.11  --batch-size=2 –truncate

该命令从源集群迁移一个数据库test_db到目标集群，目标集群的master节点IP为101.8.187.11，–truncate命令表示当执行迁移时，若发现目标集群已经数据库中已经有要迁移的表时，先进行truncate操作。
若想加快传输速率，可以通过修改参数–batch-size和–sub-batch-size来提高同时传输的表数和针对一个表起的并发数。

在迁移前，需要将表中的索引给删除，迁移完成后再进行重建。若在进行表的迁移时，对于大表使用gptransfer命令进行迁移，而对于小表，可以使用copy命令进行迁移。

在执行迁移时，出现gptransfer failed.(Reason=’fe_sendauth:’ no passwd supplied)的错误。此时，可通过修改目标集群master节点上的pg_hba.conf文件，增加对目标集群所有节点主机的信任。例如，
将host all all 0.0.0.0/0 md5修改为 host all all 0.0.0.0/0 trust

在迁移过程中，发现迁移的速度非常慢，600G左右的数据，迁移了接近两天。分析检查原因，发现：

集群网络有问题。
对于该问题，对集群进行数据的迁移前，一定要使用gpcheckpref命令进行网络，磁盘等的检测。在进行其他数据操作时，若发现异常的慢，也首先需要考虑使用gpcheckperf进行检测。
迁移过程中，表发生了死锁。
使用select * from pg_stat_activity;查看哪些操作发生了死锁。再使用select pg_terminate_backend(线程号);命令将死锁的线程给干掉。

在解决了死锁问题后，gptransfer命令结束，并显示一个错误消息并且把表名加到一个失败的传输文件中，可以查看该失败的传输文件，对于由于死锁而导致传输失败的表，单独进行传输。

集群扩容准备

在集群进行扩容前，先需要检查原集群的磁盘，网络等性能，使用gpcheckperf命令进行检测。在进行检测时，使用命令为：

gpcheckpref -f /home/gpadmin/hostfile_exkeys -r dns –d /home/gpadmin

其中hostfile_exkeys文件包含集群中所有节点的主机名。
发生如下错误：

[Error] command failed:time -p /home/gpadmin/gpcheckperf_$USER/multidd -i /dev/zero -o /home/gpadmin/gpcheckperf_$USER/ddfile -B 32768 -S 539799134208

定位该问题发现，gpcheckperf进行磁盘IO性能检查时，会默认使用2倍于主机内存的文件进行读写。当指定检测时使用的目录为/home/gpadmin/时，会在该目录下创建一个gpcheckperf_$USER目录来进行数据的读写（通过dd命令生成文件进行读写）。而由于物理机内存比较大，而/home/gpadmin/目录所在分区比较小，所以就会出现上述错误。

解决办法：
指定一个大于物理机内存两倍的目录进行测试，同时该目录必须要有gpadmin用户的写权限。

集群扩容

集群扩容可参考：
https://blog.csdn.net/hmxz2nn/article/details/86319300

在执行/home/gpadmin/目录下执行gpexpand -i gpexpand_inputfile -D expanddb时，发生错误而失败。
错误log：

ExecutionError: ‘non-zero rc: 2’ occurred. Details:’GPSTART_INTERNAL_MASTER_ONLY=1’ && /bin/tar cvPf gpexpand_schema.tar -C /opt/MPP1/disk/master/gpexpand_04102019_408836 .’ cmd had rc=2 complete=True halted=False
Stdout=’./
…
Stderr=/bin/tar:gpexpand_schema.tar:wrote only 4096 of 10240bytes
/bin/tar:Error is not recoverable:exiting now

通过本地复现及查看gpexpand命令的python文件代码得到，在执行gpexpand -i gpexpand_inputfile -D expanddb时，会有如下操作：

将master节点下的/opt/MPP1/disk/master/gpseg-1下的文件拷贝至/opt/MPP1/disk/master下的一个临时文件夹，比如gpexpand_04102019_408836
打包该临时文件夹，生成一个gpexpand_schema.tar文件。比如执行命令/bin/tar cvPf gpexpand_schema.tar -C /opt/MPP1/disk/master/gpexpand_04102019_408836 .就是将gpexpand_schema.tar打包至当前目录下，也就是/home/gpadmin/目录
将打包得到的文件拷贝至新的主机对应目录下，然后解压缩至新主机的/opt/MPP1/disk1/primary/seg-1等目录下。

同时，查看发小gpseg-1目录下文件大小大于/home/gpadmin/目录大小。由此找到问题原因所在：即原集群master节点gpseg-1目录下文件太大，导致打包时，要打包到的位置文件空间不足。

补充：
在官方文档中，对于使用gpexpand 进行扩容，有以下介绍：
在扩容前，验证master的数据目录中在pg_log或者gpperfmon/data目录下有没有极大的文件。

解决办法及注意事项：
在扩容前，确保/opt/MPP1/disk/master/seg-1目录下的文件大小不超过根目录可用空间大小。
若路径下确实有大文件，可以先移动备份到其他位置，这样既避免了可能的空间不足，又可以节省扩容时间。