Greenplum数据仓库迁移小记
迁移无小事，所以从开始计划将公司的Greenplum集群迁移，到最后落地，整个过程虽然说不上是波折，但是也算是有不少的故事，各种准备和协调。
这次的迁移是集群的物理搬迁，听起来似乎也没有太多的亮点，但是如果这个集群有上百个节点，这个难度和复杂度就会比预期高出许多。
所以对于GP集群迁移方案，难点在于服务节点多，存在全局性依赖，如果迁移完成后存在网络问题或者系统问题会导致集群全部失效，无法启动；而且集群环境涉及数据仓库，数据集市和ETL服务器，需要区别对待，制定合理的迁移方案。
这件事情如果想得简单点，迁移的难点应该是两个地方：
1）保证需要考虑双网卡绑定的配置问题，需要系统部提前规划和准备
2）网络调整后GP Master能够正常识别出新的segment节点实例（120个实例，含有primary和mirror）
需要保证的核心就是主机名不能修改，一旦发生了改变，那么GP集群就完全不可用，当然如果经历了这个过程，其实上面的只是很小的一部分工作。
首先的难点不是迁移，而是技术储备，GP技术方向相对来说小众，没有MySQL的风风火火，也没有大数据方向纯粹的分布式方案（GP是MPP分布式方案），抛开这些，会的人少，愿意学的人也少。
为了完成这个任务，自己搭建了一个GP集群，然后开始了初步的学习。整个过程虽然看起来漏洞百出，技术经验不足，对于技术的把控上算是有了一些传承吧。
当时搭建的测试环境是这样的架构，用3台虚拟机即可搞定。
迁移看起来是个技术活儿，但是迁移的是业务，所以迁移的事情肯定是要和业务挂钩的，这方面也是经常找同事老郭他们来确认和学习。对于我来说，GP的技术沉淀能够传承下来和他们的帮助密切相关，因为有些事情其实算是份外的。
然后我们来说下集群迁移中的一些准备，算是纯技术细节吧。
- 配置文件备份，为了保证迁移前和迁移后都有一个清晰的检查点和备份，我们对系统中的配置文件进行了备份，放到一个统一的目录下面。 里面尤其需要提的就是最后对于进程信息的备份，在集群启动之后，做一些跟踪和对比是大有帮助的。假设用户是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，停止其他应用，停止集群，启动集群，配置关系等等。事无巨细，还是要关注细节。