当Greenplum数据库高可用性被启用时，有两种类型的Segment：主Segment和镜像Segment。每个主Segment都有一个对应的镜像Segment。主Segment从Master接收请求来对该Segment的数据库做更改并且接着把那些更改复制到对应的镜像。如果主Segment变成不可用，数据库请求会被故障转移到镜像Segment。

Segment镜像采用了一种物理文件复制方案--主Segment上的数据文件I/O会被复制到镜像Segment，这样镜像的文件与主Segment的文件一模一样。Greenplum数据库中的数据被表示为元组，它们被打包成块。数据库表被存储在由一个或者更多块组成的磁盘文件中。对于元组的一个更改会改变其所在的块，该块接着会被写入到主Segment上的磁盘并且被通过网络复制到镜像Segment。镜像会在其文件副本中更新相应的块。

对于堆表，块被保存在一个内存中的缓冲内，直到为了给新更改的块腾空间而将它们排出。这允许系统多次在内存中读写一个块而不需要执行昂贵的磁盘I/O。当块被从缓冲中排出时，它会被写入到磁盘并且复制到镜像中。当块被保存在缓冲中时，主Segment和镜像Segment有该块的不同映像。不过，数据库仍然是一致的，因为事务日志已经被复制。如果一个镜像接替了失效的主Segment，其日志中的事务会被应用到数据库表上。

其他数据库对象（例如文件空间，它是内部由目录表示的表空间）也使用文件复制来以同步的方式执行多种文件操作。

追加优化表不使用缓冲机制。对追加优化表块的更改会被立刻复制到镜像。典型地，文件写操作是异步的，而打开、创建和同步文件是“同步复制的”，这意味着主Segment会阻塞直到它收到来自镜像Segment的确认。

如果主Segment失效，文件复制进程会停止并且镜像Segment自动地开始作为活动的Segment实例。当前活动的镜像Segment的系统状态会变成Change Tracking，这表示在主Segment不可用期间由该镜像维护系统表以及所有被更新块的改变日志。当失效的主Segment被修复并且准备好重新回到线上后，管理员可以发起一次恢复处理并且系统进入到Resynchronization状态。恢复处理会将记录下来的更改应用到已被修复的主Segment。当恢复处理完成后，系统状态会变成Synchronized。

在主Segment状态为活动时，如果镜像Segment失效或者变成不可访问，主Segment的系统状态会变成Change Tracking，并且它会跟踪更改，当镜像被恢复时将更改应用到镜像Segment。

可以以不同的配置把镜像Segment放置在集群中的主机上，只要求同一个Segment的主实例和镜像实例在不同的主机上。每台主机必须有相同数量的主Segment和镜像Segment。默认的镜像配置是组镜像，在这种配置下，每台主机的主Segment的镜像Segment被放置在其他的一台主机上。如果单个主机失效，其后备主机上的活动主Segment的数量会翻倍。图 1展示了一种组镜像配置。

散布镜像把每台主机的镜像散布在多台主机上，这样如果任何一台主机失效，其他主机都不会有超过一个镜像被提升为活动主Segment。只有当主机数量大于每台主机上的Segment数量时才能使用散布镜像。图 2展示了在一种散布Segment镜像配置中镜像的布置情况。

创建镜像Segment的Greenplum数据库工具支持组和散布Segment配置。自定义的镜像配置可以用一个文件描述，然后在命令行上传入。