Greenplum数据仓库迁移小记
迁移无小事，所以从开始计划将公司的Greenplum集群迁移，到最后落地，整个过程虽然说不上是波折，但是也算是有不少的故事，各种准备和协调。 这次的迁移是集群的物理搬迁，听起来似乎也没有太多的亮点，但是如果这个集群有上百个节点，这个难度和复杂度就会比预期高出许多。 所以对于GP集群迁移方案，难点在于服务节点多，存在全局性依赖，如果迁移完成后存在网络问题或者系统问题会导致集群全部失效，无法启动；而且集群环境涉及数据仓库，数据集市和ETL服务器，需要区别对待，制定合理的迁移方案。 这件事情如果想得简单点，迁移的难点应该是两个地方：1）保证需要考虑双网卡绑定的配置问题，需要系统部提前规划和准备2）网络调整后GP Master能够正常识别出新的segment节点实例（120个实例，含有primary和mirror） 需要保证的核心就是主机名不能修改，一旦发生了改变，那么GP集群就完全不可用，当然如果经历了这个过程，其实上面的只是很小的一部分工作。 首先的难点不是迁移，而是技术储备，GP技术方向相对来说小众，没有MySQL的风风火火，也没有大数据方向纯粹的分布式方案（GP是MPP分布式方案），抛开这些，会的人少，愿意学的人也少。 为了完成这个任务，自己搭建了一个GP集群，然后开始了初步的学习。整个过程虽然看起来漏洞百出，技术经验不足，对于技术的把控上算是有了一些传承吧。 当时搭建的测试环境是这样的架构，用3台虚拟机即可搞定。https://ask.qcloudimg.com/http-save/yehe-1341391/0jqz8tb4fx.jpeg?imageView2/2/w/1620迁移看起来是个技术活儿，但是迁移的是业务，所以迁移的事情肯定是要和业务挂钩的，这方面也是经常找同事老郭他们来确认和学习。对于我来说，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/migratecp -r /etc/sysconfig/network-scripts/home/gpadmin/migratecp /etc/hosts /home/gpadmin/migratecp /etc/hosts.allow/home/gpadmin/migratecp /home/gpadmin/.ssh/id_rsa/home/gpadmin/migratecp /home/gpadmin/.ssh/id_rsa.pub/home/gpadmin/migratecp /home/gpadmin/.ssh/authorized_keys/home/gpadmin/migratecp /home/gpadmin/.ssh/known_hosts /home/gpadmin/migratecp /var/log/dmesg /home/gpadmin/migrate 备份系统日志cp /etc/sysctl.conf /home/gpadmin/migrateps -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_5533postgres 00:00:59 /usr/local/pgsql9.5.5/bin/postgres -D /data/pgdata_5534postgres 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_5536postgres 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，停止其他应用，停止集群，启动集群，配置关系等等。事无巨细，还是要关注细节。
本文分享自微信公众号 - 杨建荣的学习笔记（jianrong-notes）
页:
[1]