目录
1.Greenplum数据库中的冗余和故障转移
1.1关于Segment的mirror
1.2Segment故障转移和恢复
1.3关于Master的mirror
2.Greenplum数据库的高可用性
2.1 mirror segment概述
2.2master mirroring概述
1.Greenplum数据库中的冗余和故障转移
可以通过部署mirror组件避免单点故障，下面将详细介绍Greenplum中master和segment的mirror策略。
1.1关于Segment的mirror
部署Greenplum数据库系统时，可以配置primary segment。mirror segment允许数据库在primary segment不可用时进行故障转移。在集群部署时，强烈建议在生产系统中使用mirror。
Mirror segemnt必须部署在与primary segment不同的主机上，以防止单个主机故障。
初始化或扩展Greenplum系统时，可以使用两种mirror配置策略。默认配置是（group mirroring ）将主机primary segment的所有mirror segment放置在群集中的另一台主机上。另外一种配置策略为spread mirroring，这种方式会将每个主机mirror分布在其余主机上，并要求群集中的主机数多于每个主机的primary segment数。下图为spread配置。
1.2Segment故障转移和恢复
在Greenplum数据库系统中启用mirror时，如果主副本不可用，系统将自动故障转移到mirror segment。如果segment实例或主机出现故障，只要所有数据在剩余的活动segment上都可用，Greenplum数据库系统就可以继续运行。
如果master服务器无法连接到segment实例，它会在Greenplum数据库系统目录(system catalog)中将该segment实例标记为down状态，并激活与其对应的segment实例。在管理员采取措施使该段重新恢复之前，失败的segment实例将保持不运行状态。使用gpstate工具可用于识别失败的segment。管理员可以在系统启动并运行时恢复故障的segment。恢复过程仅复制在segment停止运行时遗漏的更改。
如果未启用mirror，则在segment实例变为无效时，系统将自动关闭。必须先恢复所有失败的segment，然后才能继续操作。
1.3关于Master的mirror
可以在另一台主机上选择为master节点部署备份或镜像(standby master)。standby master在primary master变为不可操作的情况下充当热备主机。standby master通过事务日志复制进程来保持与primary master相同的状态，该进程运行在standby master上，用于standby master和primary master之间同步数据。
如果primary master出现故障，则日志复制进程将停止，此时可以激活standby master。但是切换不会自动发生，必须通过外部触发。激活standby master后，复制的日志用于在上次成功提交事务时重建primary master的状态。激活的standby master将成为Greenplum数据库的primary master，使用primary master的端口号接受客户端连接（必须在primary master和standby master设置相同的端口号，默认端口号为5432）。
由于primary master不包含任何用户数据，因此只需要在主master和备份master之间同步系统目录表(catalog tables)。当这些表发生更新时，更改的结果会自动复制到备用master上，以确保与主master同步。下图为greenplum中的master mirror。
2.Greenplum数据库的高可用性
2.1 mirror segment概述
当启用Greenplum数据库高可用性时，有两种类型的segment：primary和mirror。每个主segment具有一个对应的mirror segment。主segment接收来自master的请求以更改主segment的数据库，然后将这些更改复制到相应的mirror segment上。如果主segment不可用，则数据库查询将故障转移到mirror segment上。
Mirror segment采用物理文件复制的方案---primary segment中数据文件I / O被复制到mirror segment上，因此mirror segment的文件与primary segment上的文件相同。Greenplum数据库中的数据用元组(tuple)表示，元组被打包成块（block）。数据库的表存储在由一个或多个块组成的磁盘文件中。对元组进行更改操作，同时会更改保存的块，然后将其写入primary segment上的磁盘并通过网络复制到mirror segment。Mirror segment只更新其文件副本中的相应块。
对于堆表(heap)而言，块被保存在内存缓存区中，直到为新更改的块腾出空间时，才会将它们清除，这允许系统可以多次读取或更新内存中的块，而无需执行昂贵的磁盘I / O。 当块从缓存中清除时，它将被写入磁盘并复制到mirror segment主机的磁盘。当块保存在缓存中时，primary segment和mirror segment具有不同的块镜像，但是，数据库仍然是一致的，因为事务日志已经被复制了。
AO表(Append-optimized)不使用内存缓存机制。对AO表的块所做的更改会立即复制到mirror segment上。通常，文件写入操作是异步的，但是打开、创建和同步文件是“同步复制”的，这意味着primary segment的块需要从mirror segment上接收确认。
如果primary segment失败，则文件复制进程将会停止，mirror segment会自动作为活动segment实例，活动mirror segment的系统状态会变为“ 更改跟踪”(Change Tracking)，这意味着在primary segment不可用时，mirror segment维护着一个系统表和记录所有块的更改日志。当故障的primary segment被修复好，并准备重新上线时，管理员启动恢复过程，系统进入重新同步状态。恢复过程将记录的更改日志应用于已修复的primary segment上。恢复过程完成后，mirror segment的系统状态将更改为“已同步 ”。
如果mirror segment在primary segment处于活动状态时失败或无法访问，则primary segment的系统状态将更改为“ 更改跟踪”，并且它会记录更改的状态，用于mirror segment的恢复。
（1）group mirroring方式
只要primary segment实例和mirror segment实例位于不同的主机上，mirror segment就可以以不同的配置方式放置在群集中的主机上。每个主机必须具有相同数量的mirror segment和primary segment。默认mirror segment配置方式是group mirroring，其中每个主机的primary segment的mirror segment位于另一个主机上。如果单个主机发生故障，则部署该主机的mirror segment主机上的活动primary segment数量会翻倍，从而会加大该主机的负载。下图说明了group mirroring配置。
（2）Spread mirroring方式
Spread mirroring方式是指将每个主机的mirror segment分布在多个主机上，这样，如果任何单个主机发生故障，该主机的mirror segment会分散到其他多个主机上运行，从而达到负载均衡的效果。仅当主机数量多于每个主机的segment数时，才可以使用Spread方式。下图说明了Spread mirroring方式。
2.2master mirroring概述
可以在单独的主机或同一主机上部署master实例的备份或镜像。如果primary master服务器宕机，则standby master服务器将用作热备用服务器。在primary master服务器在线时，可以从primary master服务器创建备用master服务器。
Primary master服务器持续为用户提供服务，同时获取Primary master实例的事务快照。在standby master服务器上部署事务快照时，还会记录对primary master服务器的更改。在standby master服务器上部署快照后，更新也会被部署，用于使standby master服务器与primary master服务器同步。
Primary master服务器和备用master服务器同步后，standbymaster服务器将通过walsender 和 walreceiver 的复制进程保持最新状态。该walreceiver是standby master上的进程， walsender进程是primary master上的进程。这两个进程使用基于预读日志（WAL）的流复制来保持primary master和standby master服务器同步。在WAL日志记录中，所有修改都会在应用生效之前写入日志，以确保任何进程内操作的数据完整性。
由于primary master不包含任何用户数据，因此只需要在主master和备份master之间同步系统目录表(catalog tables)。当这些表发生更新时，更改的结果会自动复制到备用master上，以确保与主master同步。
如果primary master发生故障，管理员需要使用gpactivatestandby工具激活standby master。可以为primary master和standby master配置一个虚拟IP地址，这样，在primary master出现故障时，客户端程序就不用切换到其他的网络地址，因为在master出现故障时，虚拟IP地址可以交换到充当primary master的主机上。