迁移无小事，所以从开始计划将公司的Greenplum集群迁移，到最后落地，整个过程虽然说不上是波折，但是也算是有不少的故事，各种准备和协调。 

    这次的迁移是集群的物理搬迁，听起来似乎也没有太多的亮点，但是如果这个集群有上百个节点，这个难度和复杂度就会比预期高出许多。  

    所以对于GP集群迁移方案，难点在于服务节点多，存在全局性依赖，如果迁移完成后存在网络问题或者系统问题会导致集群全部失效，无法启动；而且集群环境涉及数据仓库，数据集市和ETL服务器，需要区别对待，制定合理的迁移方案。

    这件事情如果想得简单点，迁移的难点应该是两个地方：

1）保证需要考虑双网卡绑定的配置问题，需要系统部提前规划和准备

2）网络调整后GP Master能够正常识别出新的segment节点实例（120个实例，含有primary和mirror）

    需要保证的核心就是主机名不能修改，一旦发生了改变，那么GP集群就完全不可用，当然如果经历了这个过程，其实上面的只是很小的一部分工作。

    首先的难点不是迁移，而是技术储备，GP技术方向相对来说小众，没有MySQL的风风火火，也没有大数据方向纯粹的分布式方案（GP是MPP分布式方案），抛开这些，会的人少，愿意学的人也少。

    为了完成这个任务，自己搭建了一个GP集群，然后开始了初步的学习。整个过程虽然看起来漏洞百出，技术经验不足，对于技术的把控上算是有了一些传承吧。

    当时搭建的测试环境是这样的架构，用3台虚拟机即可搞定。

        迁移看起来是个技术活儿，但是迁移的是业务，所以迁移的事情肯定是要和业务挂钩的，这方面也是经常找同事老郭他们来确认和学习。对于我来说，GP的技术沉淀能够传承下来和他们的帮助密切相关，因为有些事情其实算是份外的。

        然后我们来说下集群迁移中的一些准备，算是纯技术细节吧。

1. 配置文件备份，为了保证迁移前和迁移后都有一个清晰的检查点和备份，我们对系统中的配置文件进行了备份，放到一个统一的目录下面。

   里面尤其需要提的就是最后对于进程信息的备份，在集群启动之后，做一些跟踪和对比是大有帮助的。假设用户是gpadmin,我们创建一个目录migrate

mkdir -p /home/gpadmin/migrate    

iptables -nvL > /home/gpadmin/migrate/iptables_online   内存层面的防火墙信息

cp /etc/sysconfig/iptables   /home/gpadmin/migrate      系统层面的防火墙文件

cp /etc/sysconfig/network    /home/gpadmin/migrate

cp -r /etc/sysconfig/network-scripts  /home/gpadmin/migrate

cp /etc/hosts    /home/gpadmin/migrate

cp /etc/hosts.allow  /home/gpadmin/migrate

cp /home/gpadmin/.ssh/id_rsa  /home/gpadmin/migrate

cp /home/gpadmin/.ssh/id_rsa.pub  /home/gpadmin/migrate

cp /home/gpadmin/.ssh/authorized_keys  /home/gpadmin/migrate

cp /home/gpadmin/.ssh/known_hosts   /home/gpadmin/migrate

cp /var/log/dmesg     /home/gpadmin/migrate   备份系统日志

cp /etc/sysctl.conf    /home/gpadmin/migrate

ps -ef|grep post  > /home/gpadmin/migrate/ps_os.lst

    2.备份GP，PG配置文件pg_hba.conf

    因为有上百个节点，所以节点的目录结构会非常复杂，这部分的信息需要提前抓取，提前配置。

    3.GPCC的配置备份。

    GPCC这个工具整体来说还不错，为了保证迁移前后的可用性，最后确认了下只需要修改下基本的配置文件即可。最坏的打算是GPCC无法启动，我需要重新搭建和配置。

    4.PG的配置和备份

比如有下面的一些PG实例，就需要提前把元信息记录下来，方便后续的改动和配置。

-> ps -ef|grep post|grep data 

postgres   00:00:59 /usr/local/pgsql9.5.5/bin/postgres -D /data/pgdata_5533

postgres   00:00:59 /usr/local/pgsql9.5.5/bin/postgres -D /data/pgdata_5534

postgres   00:00:58 /usr/local/pgsql9.5.5/bin/postgres -D /data/pgdata_5535  +

postgres   00:00:58 /usr/local/pgsql9.5.5/bin/postgres -D /data/pgdata_5536

postgres   00:05:00 /usr/local/pgsql9.5.5/bin/postgres -D /data/pgdata_5532

    5.其他的服务和配合

     在检查的时候，突然发现部分GP，PG的元数据有一个MySQL库在存放，还有一个web应用opencron在运行，还有一个Django自建项目在运行，整个的过程会比开始的时候规划的要复杂很多，比如相关的opencron的agent都需要重启和配置，这个时候发现里面的很多信息都是一环扣一环。

    6.备份crontab信息和配置

    crontab的信息在ETL端是信息大户，这部分的信息还是需要提前备份。

    7.监控的配置

    监控是整个环节的一个辅助亮点，需要确保在迁移过程中不会有报警风暴。

    8.数据的备份

    这部分的备份，只能取到最小的结果集，对于GP集群而言，最起码的DDL配置是要备份的，对于PG而言，属于数据集市，结果集不大，所以可以考虑同步数据到其他的集群或者节点上。

整个迁移的过程和迁移后的一些小结：

    1.对于停止GP集群，我们采用了如下的方式：

    停止GP集群

    重启GP集群

    停止GP集群

   这样确保集群没有任何明显的问题，迁移后是一个相对纯粹的环境。

  2.迁移后对于集群节点的关系可以使用gpssh来前期验证，千万不要着急重启GP集群，准备好了一气呵成。

   3.对于GP节点间的互信关系，需要配置/etc/hosts.allow这个配置是之前测试中遗漏的。

    4.对于segment节点中的pg_hba.conf配置，其实涉及的点非常多，每个节点有差不多5条变更，整体下来就是接近上千条变更了。这个过程一定要使用脚本，备份好之后果断使用。

    5.对于应用层面的权限和配置等，虽然看起来简单，琐碎，但是这个过程却是也绕不过去，还是得花不少的功夫来反复确认。

    集群的迁移来说，基本就是修改IP，停止其他应用，停止集群，启动集群，配置关系等等。事无巨细，还是要关注细节。