@
1. 问题描述
在项目中使用了Greenplum做分析型数据库，Greenplum自身已经提供了高可用方案，Master节点提供Sdanby备用节点，Segment数据节点每个节点都有对应mirro节点。
但是Greenpplum提供的高可用方案，其实是存在缺陷的，就是master节点出现故障后，standby节点是不会自动启动的，需要人工干预（segment数据节点会自动切换），这样就会导致两个问题：
（1）当Greenpplum的Master节点出现故障后，需要人工干预去激活并切换到Standby节点，一般公司是有运维团队的，会通过进程监控并通知相关人员来处理，但是这个过程是需要一定时间的，假如用户在使用，肯定会有所感知的，会影响实际业务。
（2） 最致命的是将主节点切换到Standby节点后，Greenpplum的访问IP发生了变化，这时候连接Greenpplum的Web服务必须修改连接IP才能访问，一般情况下是需要重启应用服务器的，假如连接Greenpplum的是多个系统，并且是以集群的方式部署启动的的，重启的代价可能会很高。
2. 解决方案
2.1 Greenplum架构简单介绍
2.1.1 Greenplum架构图
数据库连接通过Master节点进行访问，跟oracle、mysql、postgre等关系型数据库连接方式一样
2.1.2 Greenplum提供的高可用方案
主节点Master节点有standby备用节点，数据节点segement存在mirrio（一般存储在临近服务器上）。
2.2 使用keepalived+greenplum实现真正的高可用
2.2.1 keepalived+greenplum架构图
2.2.2 架构图解析
（1） 在Greenplum的master节点和standby节点部署keepalive服务，使用keepalive监控greenplum的进程状态和服务可用性；
（2） 采用keeplived的机制，在master和standby 上面生成一个虚拟IP，应用系统配置的连接地址为该虚拟IP地址，当master节点出现故障后，由Keepalived机制来保证切换到standby节点，需要特别注意的是切换到standby节点的时候，需要首先激活Standby节点，这样就解决了greenplum主备节点的无缝切换
2.3 高可用方案存在的问题
该高可用方案是通过比较成熟的keepalived来保证主从节点的切换，弥补了Greenplum本身高可用架构的不足，基本能解决大部分问题，认为是可行的。
但是也存在不足之处，就是假如主节点上的keepalived出现了故障，但是Greenplum服务正常；这时候虚拟IP已经漂移到Standby对应IP节点，但是因为Greenplum的Master服务其实是正常，Standby服务会激活失败，进而导致服务不可用，但是该情况几率较小，后续可以考虑将keepalived进程增加到运维进程监控中。