Deepgreen & Greenplum 高可用（一） - Segment节点故障转移Deepgreen & Greenplum 高可用（二） - Master故障转移

尚书中云：惟事事，乃其有备，有备无患。这教导我们做事一定要有准备，做事尚且如此，在企事业单位发展中处于基础地位的数据仓库软件在运行过程中，何尝不需要有备无患呢？

今天别的不表，主要来谈谈企业级数据仓库软件deepgreen和greenplum的高可用特性之一：计算节点镜像。

一、首先从理论上来讲，正常segment节点和他的mirror是分布在不同主机上的，以防止单点故障导致的数据库访问异常。当正常segment节点出现故障时，mirror节点可以自动接管segment节点的服务，数据库仍然可以正常使用。这个过程对前台应用来说是透明的。

下面我们来看实操例子：

1.测试环境

2.首先查看集群状态：1 master，2 segments

3.创建镜像节点目录并添加节点

4.重新查看集群状态：确定2个segments都已经添加好mirror

5.登录数据库进行查询测试

6.模拟实验：segment1实例异常

7.访问数据库测试连通性：仍然可以正常查询

8.查看集群状态：显示有1个primary节点异常

至此本实验完成，可以看到，在segment主实例异常情况下，mirror会立即接管服务，不会对前台应用产生停机影响。

实验完成了，但是事情还没有结束哦，因为这是故障，所以故障产生后，需要进行修复，那么基于整个集群，我们都需要做什么呢？

要点一：及时恢复故障节点

要点二：虽然mirror可以临时接管服务，保持服务的连续性，但是在实际生产过程中，由于节点及其mirror的分散性，长期使用mirror会导致数据分布不均匀，所以故障修复后，建议及时切换回原来的架构。

二、故障节点恢复

节点在故障以后，可以通过gprecoverseg命令恢复故障节点，如下：

查看集群状态

三、切换回原集群状态

从第二部分的最后状态代码也可以看出，目前是一个mirror节点接管了primary节点的服务，我们本节要讲mirror的服务交还给primary。

下面执行：gprecoverseg -r 命令进行节点切换，切换完成后执行gpstate查看状态，代码略。

另外，我们也可以在数据库里面通过字典表查看切换信息：

这样，整个今天的分享就结束了，最后再啰嗦一句。从本文例子看出，数据库主/备切换相当的简单，gprecoverseg命令相当的智能，在primary的主机出现故障之后，mirror会自动切换为primary，不影响数据库的正常工作，但是对监控不是很到位的系统来说，不建议使用这个功能，首先这个功能存在一定的bug，其次，监控不到位，一旦发现切换，并不能及时发现，如果再有节点出现故障，可能对数据恢复造成影响，而且如果单个节点的数据量非常大的时候，gprecoverseg同步数据的过程将会很漫长。

最后，祝大家再deepgreen & greenplum的路上一去不复返^_^

同系列文章参考：