Greenplum数据库高可用性概述
Tags： GPDBGreenPlumGroup mirroringSpread mirroring概述高可用
简介
当Greenplum数据库 集群不允许数据丢失时，master和segment镜像功能必须启用。没有镜像就不能保证系统和数据的 高可用，此时Pivotal会尽最大的努力恢复故障集群。当用户启用并且正确地配置Greenplum高可用特性时，Greenplum数据库支持高度可用的、容错的数据库服务。 要保证达到要求的服务等级，每个组件都必须有一个备用组件以保证在它失效时及时顶上。
Greenplum数据库系统的高可用可以通过提供容错硬件平台实现，可以通过启用Greenplum数据库高可用特性实现， 也可以通过执行定期监控和运维作业来确保整个系统所有组件保持健康来实现。
硬件平台的最终故障，可能因为常见的持久运行故障或非预期的运行环境。异常断电会导致组件临时不可用。系统可以 通过为可能故障的节点配置冗余备份节点来保证异常出现时仍能够不间断提供服务。在一些情况下，系统冗余的成本高于 用户的服务终端容忍度。此时，高可用的目标可以改为确保服务能在预期的时间内恢复。
Greenplum数据库的容错和高可用通过以下几种方式实现：
磁盘存储(硬件级别RAID)
Greenplum数据库部署最佳实践是采用硬件级别的RAID为单盘失败的情况提供高性能的磁盘冗余，避免只采用 数据库级别的容错机制。该方式可以在磁盘级别提供低级别的冗余保护。
源于Greenplum数据库的非共享MPP架构，每台master和segment主机都有它们自己独立的内存和磁盘存储空间， 每个master和segment实例都有它们自己独立的数据目录。为了兼顾可靠性和高性能，Pivotal推荐采用8到24块 磁盘的硬件RAID存储解决方案。当采用RAID5或RAID6时，大量的磁盘会提升I/O吞吐量，因为条带会增加并行的 磁盘I/O。有一个失效磁盘时，RAID控制器能够继续工作，因为它在每个磁盘上都保存了校验数据，这样它能够重构 阵列中任何失效磁盘上的数据。如果配置了热备盘（或者配置了能够用新磁盘替代故障磁盘的操作器），控制器能够 自动重建故障磁盘。
在RAID1模式下，实际上就是镜像一组磁盘，因此如果出现某块磁盘故障，替代磁盘立即可用，并且性能与出现磁盘 故障之前无二。在RAID5模式下，故障磁盘上的每一个数据I/O都必须从剩余活动磁盘上重建出来，直到故障磁盘重建 完成，因此会出现一段时间的性能下降。如果磁盘数据重建期间，Greenplum数据库master和segment配置了镜像 实例，您可以将任何受到影响的Greenplum数据库实例切换为它们的镜像以保证性能最优。
RAID磁盘阵列仍然可能会出现单点故障，例如整个RAID卷故障。在硬件级别上，可以通过RAID控制器提供的镜像功 能或操作系统提供的镜像功能来防范磁盘阵列故障。
定期监控每台主机的可用磁盘空间是很重要的。可以通过查询gptoolkit模式下的外部表 gp_disk_free来查看segment节点的磁盘可用空间。该视图会运行Linux命令df。 在执行占用大量磁盘空间的操作（例如copy大表）前要确保检查可用磁盘空间。
最佳实践
- 使用带有8到24个磁盘的硬件RAID存储方案。
- 使用RAID 1、5或6，这样磁盘阵列能容忍一个故障磁盘。
- 在磁盘阵列中配置一个热备盘以允许在检测到磁盘失效时自动开始重建。
- 通过镜像RAID磁盘组防止整个磁盘阵列的故障和重建期间的性能衰退。
- 定期监控磁盘利用率并且在需要时增加额外的磁盘空间。
- 监控segment数据倾斜以确保所有segment节点的数据均匀分布、空间合理利用。
数据存储总和校验
Greenplum数据库采用总和校验机制在文件系统上验证从磁盘加载到内存的数据没有被破坏。
Greenplum数据库有两种存储用户数据的方式：堆表和追加优化表。两种存储模型均采用总和校验机制 验证从文件系统读取的数据，默认配置下，二者采用总和校验机制验证错误的方式基本类似。
Greenplum数据库master和segment实例在他们所管理的自有内存中更新页上的数据。当内存页被更新 并刷新到磁盘时，会执行总和校验并保存起来。当下次该页数据从磁盘读取时，先进行总和校验，只有成功 通过验证的数据才能进入管理内存。如果总和校验失败，就意味着文件系统有损坏等情况发生，此时Greenplum 数据库会生成错误并中断该事务。
默认的总和校验设置能提供最好的保护，可以防止未检测到的磁盘损坏影响到数据库实例及其镜像Segment节点。
堆表的总和校验机制在Greenplum数据库采用gpinitsystem初始化时默认启用。我们可以通过设置 gpinitsystem配置文件中的HEAP_CHECKSUM参数为off来禁用堆表的总和校验 功能，但是我们强烈不推荐这么做，详见gpinitsystem。
一旦集群初始化完成，就不能改变堆表总和校验机制在该集群上的状态，除非重新初始化系统并重载数据库。
可以通过查看只读服务器配置参数 data_checksums 来查看 堆表的总和校验是否开启。
1 | $ gpconfig -s data_checksums |
当启动Greenplum数据库集群时，gpstart工具会检查堆表的总和校验机制在master和所有segment 上是启用了还是禁用了。如果有任何异常，集群会启动失败。详情请见gpstart。
在一些情况下，为了保证数据及时恢复有必要忽略堆表总和校验产生的错误，设置ignore_checksum_failure系统配置参数为on会使在堆表总和校验失败时只生成一个警告信息，数据页仍然可以被夹在到管理内存中。 如果该页被更新并存到磁盘，损坏的数据会被复制到镜像segment节点。因为该操作会导致数据丢失，所以只有在启用数据 恢复时才允许设置ignore_checksum_failure参数为on。
追加优化存储表的总和校验可以在使用CREATE TABLE命令创建表时定义。默认的存储选项在 gp_default_storage_options服务器配置参数中定义。checksum 存储选项默认被启用并且强烈不建议禁用它。
如果想要禁用追加优化表上的总和校验机制，你可以
- 在创建表时，修改gp_default_storage_options配置参数包含checksum=false 或
- 增加checksum=false选项到CREATE TABLE语句的WITH storage_options语法部分。
注意CREATE TABLE允许为每一个单独的分区表设置包括checksums在内的存储选项。
查看CREATE TABLE命令参考和gp_default_storage_options配置文件参考语法和示例。
Segment镜像
Greenplum数据库将数据存储在多个segment实例中，每一个实例都是Greenplum数据库的一个PostgreSQL实例， 数据依据建表语句中定义的分布策略在segment节点中分布。启用segment镜像时，每个segment实例都由一对 primary和mirror组成。镜像segment采用基于预写日志（WAL）流复制的方式保持与主segment 的数据一致。详情请见Segment镜像概述。
镜像实例通常采用gpinitsystem或gpexpand工具进行初始化。 作为最佳实践，为了保证单机失败镜像通常运行在与主segment不同的主机上。将镜像分配到不同的主机上也有不同 的策略。当搭配镜像和主segment的放置位置时，要充分考虑单机失败发生时处理倾斜最小化的场景。
Greenplum数据库的每一个segment实例都在master实例的协调下存储和管理数据库数据的一部分。如果任何未配置 镜像的segment故障，数据库可能不得不被关闭然后恢复，并且在最近备份之后发生的事务可能会丢失。因此，镜像 segment是高可用方案的一个不可或缺的元素
Segment镜像是主segment的热备。Greenplum数据库会检测到segment何时不可用并且自动激活其镜像。在正常操作 期间，当主segment实例活动时，数据以两种方式从主segment复制到镜像segment：
- 在事务被提交之前，事务提交日志被从主segment复制到镜像segment。这会确保当镜像被激活时，主segment 上最后一个成功的事务所作的更改会出现在镜像上。当镜像被激活时，日志中的事务会被应用到镜像中的表上。
- 第二种，segment镜像使用物理文件复制来更新堆表。Greenplum服务器在磁盘上以打包了元组的固定尺寸块 的形式存储表数据。为了优化磁盘I/O，块被缓冲在内存中，直到缓存被填满并且一些块必须被挤出去为新更新 的块腾出空间。当块被从缓存中挤出时，它会被写入到磁盘并且通过网络复制到镜像。因为缓冲机制，镜像上的 表更新可能落后于主segment。不过，由于事务日志也被复制，镜像会与主segment保持一致。如果镜像被激活， 激活过程会用事务提交日志中未应用的更改更新表。
当活动的主segment不能访问其镜像时，复制会停止并且主segment的状态会改为“Change Tracking”。主segment 会把没有被复制到镜像的更改保存在一个系统表中，等到镜像重新在线时这些更改会被复制到镜像。
Master会自动检测segment故障并且激活镜像。故障时正在进行的事务会使用新的主segment重新开始。根据镜像被 部署在主机上的方式，数据库系统可能会不平衡直到原始的主segment被恢复。例如，如果每台segment主机有四个主 segment和四个镜像segment，并且在一台主机上有一个镜像segment被激活，那台主机将有五个活动的主segment。 查询直到最后一个Segment完成其工作才算结束，因此性能可能会退化直至原始的主segment被恢复使得系统恢复平衡。
当Greenplum数据库运行时，管理员通过运行gprecoverseg工具执行恢复。这个工具会定位 故障的segment、验证它们是否有效并且与当前活动的segment对比事务状态以确定segment离线期间发生的更改。 gprecoverseg会与活动segment同步更改过的数据库文件并且将该segment重新拉回到在线 状态。
在故障期间，有必要在segment主机上保留足够的内存和CPU资源，以允许承担了主segment觉得的镜像实例能提供 对应的活动负载。为Greenplum数据库配置内存中提供的配置 segment主机内存的公式包括一个因子，它代表故障期间任一主机上的最大主segment数量。segment主机上的镜像 布置会影响这一因子以及系统在故障时将如何应对。Segment镜像选项的讨论请见Segment镜像配置。
Segment镜像概述
当Greenplum数据库高可用性被启用时，有两种类型的Segment：primarySegment 和mirrorSegment。每个主Segment都有一个对应的镜像Segment。主Segment从 Master接收请求来对该Segment的数据库做更改并且接着把那些更改复制到对应的镜像。 如果主Segment变成不可用，镜像segment会切换为主segment，不可用的主segment会切换为 镜像segment。故障出现时正在进行的事务会回滚并且必须重启数据库。接下来管理员必须恢复镜像segment，并 允许镜像segment与当前主segment进行同步，最后需要交换主segment和镜像segment的角色，让他们处于自己 最佳的角色状态。
如果segment镜像未启用，当出现segment实例故障时，Greenplum数据库系统会关闭。管理员必须手工恢复所有 失败的segment实例然后才能重新启动数据库。
如果现有系统已经启用了segment镜像，当主segment实例正在生成一个快照时，主segment实例继续为用户提供服务。 当主segment快照完成并向镜像segment实例部署时，主segment的变化也会被记录。当快照完全部署到镜像segment 后，镜像segment会同步这些变化并采用WAL流复制的方式与主segment保持一致。Greenplum数据库的WAL复制使用 walsender和walreceiver复制进程。 walsender进程是主segment的进程。walreceiver进程是镜像segment 的进程。
当数据库变化出现时，日志捕获到该变化然后将变化流向镜像segment，以保证镜像与其对应的主segment一致。在WAL 复制期间，数据库变化在被应用之前先写入日志中，以确保任何正在处理的数据的完整性。
当Greenplum数据库检测到主segment故障时，WAL复制进程停止，镜像segment自动接管成为活动主segment。如果 主segment活动时，镜像segment故障或变得不可访问，主segment会追踪数据库变化并记录在日志中，当镜像恢复后 应用到镜像节点。有关segment故障检测和故障处理的详细信息，请见 检测故障的Segment。
Greenplum数据库系统表包含镜像和复制的详细信息。
- 系统表 gp_segment_configuration包含主segment、镜像segment、主master和standby master实例的当前配置和 状态信息。
- 系统视图gp_stat_replication包含Greenplum数据库master和segment镜像功能使用的walsender 进程的复制状态统计信息。
最佳实践
- 为所有segment设置镜像。
- 将主segment及其镜像放置在不同主机上以防止主机失效。
- 镜像可以放在一组单独的主机上或者主segment所在的主机上。
- 设置监控，当主segment故障时在系统监控应用中发送通知或者通过邮件通知。
- 即使恢复失效的segment，使用gprecoverseg工具来恢复冗余并且让系统回到最佳的 平衡状态。
关于Segment镜像配置
镜像segment实例可以根据配置的不同在集群主机中按不同的方式分布。作为最佳实践，主segment和它对应的镜像 放在不同的主机上。每台主机必须有相同的主和镜像segment。当你使用Greenplum工具gpinitsystem或 gpaddmirrors创建segment镜像时，可以设定segment镜像方式：以分组的方式镜像（默认）或 以打散的方式镜像。采用gpaddmirrors命令时，可以先创建gpaddmirrors 配置文件，然后将文件放在命令行读取执行。
以分组的方式镜像是默认的镜像方式。该方式每台主机的主segment对应的镜像都整体放在另一台主机上， 如果有一台主机故障，另外一台接管该主机服务的镜像所在的机器的活动segment数量便会翻倍。 图表 Figure 1 显示了以分组的方式配置segment镜像。
Figure 1. 以分组的方式在Greenplum数据库中分布镜像 
以打散的方式镜像 将每一个主机的镜像分散到多台主机上，保证每一个机器上至多只有一个 镜像提升为主segment，这种方式可以防止单台主机故障后，另外的主机压力骤增。以打散方式镜像 分布要求集群主机数量多于每台主机上segment的数量。图表Figure 2显示了如何以打散的方式配置segment镜像。
Figure 2. 以打散的方式在Greenplum数据库中分布镜像 
Segment镜像配置
Segment镜像允许数据库查询在主Segment故障或者不可用时转移到备份segment上。Pivotal要求在其支持的 Greenplum数据库生产环境中必须配置镜像。
为了确保高可用，主segment及其镜像必须位于不同主机上。Greenplum数据库系统中的每一台主机都有相同数量 的主segment和镜像segment。多宿主主机应该在每个接口上有相同数量的主segment和镜像segment。这能确保 所有主segment运行时，segment主机和网络资源的负载均衡，并且提供最多的资源承担查询处理。
当segment变得不可用时，它位于另一台主机上的镜像segment会变成活动的主segment继续处理请求。主机上的 额外负载会导致倾斜以及性能下降，但是最起码可以保证系统继续可用。数据库查询会等待系统中所有segment都 返回结果后结束，所以当台主机上将镜像提升为主segment和在系统中每台机器都增加一个segment实例是相同的 效果。
在故障场景下，每台主机上替代故障segment的镜像实例不超过一个时，整个数据库系统的性能下降最小。如果多个 segment或主机故障，性能下降的影响受那台唤起镜像实例最多的机器影响。将一台主机的镜像散布在其余的主机上 可以最小化任意单主机故障时的性能下降。
也有必要考虑集群对多主机故障的容忍能力，以及通过增加主机来扩展集群时如何维护镜像配置。没有一种镜像配置 是放之四海而皆准的解决方案。
您可以采用两种镜像标准配置方式中的任意一种来在主机上配置镜像方式，也可以设计您自己的镜像配置方案。
两种标准的镜像配置方式分别是group mirroring和spread mirroring：
- Group mirroring — 每台主机镜像另外机器的主segment。这是 gpinitsystem和gpaddmirrors的默认选项。
- Spread mirroring — 镜像分散分布在另外的机器上。这要求集群中的主机数量多于每台主机上的 segment实例数量。
您可以设计一个客户镜像配置文件然后使用Greenplum工具gpaddmirrors或 gpmovemirrors进行 配置。
Block mirroring一种自定义镜像配置，它把集群中的主机划分成相等尺寸的块并且在块内的主机上均匀 地分布镜像。如果一个主segment故障，其在同一个块的另一主机上的镜像会变成活动的主segment。如果一台segment 主机故障，在该块中其他每一台主机上的镜像segment都会变成活动segment。
以下部分比较group, spread, 和block mirroring镜像配置。
Group Mirroring
Group mirroring是最容易设置的镜像配置，并且是Greenplum的默认镜像配置。组镜像的扩展代价最低，因为 可以通过增加仅仅两台主机来完成扩展。在扩展之后无需移动镜像来维持镜像配置的一致性。
下面的图显示了一个在四台主机上带有八个主segment的group mirroring配置。
除非同一个segment实例的主segment和镜像都出现故障，最多可以有一半的主机故障并且集群将继续运行，只要 资源（CPU、内存和IO）足以满足需求。
任何主机故障将会让性能退化一半以上，因为具有镜像的主机将承担两倍的活动主segment。如果用户的资源利用 通常会超过50%，用户将不得不调整其负载，直至故障主机被恢复或者替换。如果用户通常的资源利用低于50%，则 集群会继续以退化的性能水平运行，直至故障被修复。
Spread Mirroring
通过spread mirroring，每台主机的主要Segment的镜像被散布在若干台主机上，涉及到的主机数量与每台主机上 segment数量相同。在集群初始化时设置spread mirroring很容易，但是要求集群中的主机数至少为每台主机上的 segment数加一。
下面的图展示了一个在四台主机上有三个主segment的集群的spread mirroring配置。
扩展使用spread mirroring的集群要求更多的规划并且可能会花费更多时间。用户必须要么增加一组数量等于每台 主机上主segment数加一的主机，要么在group mirroring配置中增加两个节点并且在扩展完成后移动镜像来重建 spread mirror配置。
对于单主机故障，spread mirroring的性能影响最小，因为每台主机的镜像都散布在多台主机上。负载的增加是 1/Nth，其中N是每台主机上主segment的数量。如果两台以上主机同时故障，spread mirroring 是最有可能遭受到灾难性故障的配置方案。
Block Mirroring
对于block mirroring，节点被划分成块，例如具有四台或者八台主机的块，而每台主机上segment的镜像被放置在 块中的其他主机上。根据块中主机的数量以及每台主机上主segment的数量，每台主机会为其他每一台主机的segment 维护超过一个镜像。
下面的图展示了单block mirroring配置，块中有四台主机，每台主机有八个主segment：
如果有八台主机，则额外增加的一个四主机块中有32至63号主segment的镜像，其设置也是同样的模式。
使用block mirroring的集群很容易扩展，因为每一个块都是一个自包含的主镜像组。集群可以通过增加一个或者多个 块来扩展。扩展之后无需移动镜像来维持镜像设置的一致。只要故障的主机处于不同的块中，这种配置就能够容忍多主机 故障。
因为块中的每台主机都有块中其他每台主机的多个镜像实例，对于主机故障block mirroring的性能影响比spread mirroring更大，但比group mirroring影响要小。预期的性能影响随着块尺寸和每节点主segment数变化。和group mirroring类似，如果资源可用，性能将会受到负面的影响，但是集群仍将可用。如果资源不足以容纳增加的负载，用户 必须降低负载直至故障节点被替换。
实现Block Mirroring
在用户设置或者扩展集群时，block mirroring并非Greenplum数据库提供的一种自动选项。要使用block mirroring， 用户必须创建自己的配置。
对于一个新的Greenplum系统，用户可以把集群初始化为没有镜像，然后用一个自定义镜像配置文件运行 gpaddmirrors -i mirror_config_file来为每一个块创建镜像。 在用户运行gpaddmirrors之前，用户必须为镜像segment创建文件系统位置。详见Greenplum 数据库管理工具指南中的gpaddmirrors参考页。
如果用户扩展一个有block mirroring的系统或者用户想要在扩展集群时实现block mirroring，推荐用户先用默认的 grouping mirror配置完成扩展，然后使用gpmovemirrors工具把镜像移到块配置中。
要在使用不同镜像方案的现有系统中实现block mirroring，用户必须首先根据其块配置确定每个镜像的位置，然后确定 哪些现有的镜像必须被重定位。按照下列步骤：
运行下列查询来查找主segment和镜像segment的当前位置：
1SELECT dbid, content, role, port, hostname, datadir FROM gp_segment_configuration WHERE content > -1 ;The gp_segment_configuration系统目录表包含当前的segment配置。
用当前镜像位置和想要的block mirroring位置创建一个列表，然后从中移除已经在正确主机上的镜像。
用列表中必须要移动的每一个项（镜像）为gpmovemirrors工具创建一个输入文件。
gpmovemirrors输入文件的格式如下：
1contentID:address:port:data_dir new_address:port:data_dirWhere contentID 是segment实例的contentID， address是对应主机的主机名或IP地址， port是通信端口，data_dir是segment实例的数据目录
下面的gpmovemirrors输入文件定义了三个需要移动的镜像segment。
1231:sdw2:50001:/data2/mirror/gpseg1 sdw3:50001:/data/mirror/gpseg12:sdw2:50001:/data2/mirror/gpseg2 sdw4:50001:/data/mirror/gpseg23:sdw3:50001:/data2/mirror/gpseg3 sdw1:50001:/data/mirror/gpseg3用以下命令运行gpmovemirrors：
1gpmovemirrors -i mirror_config_file
gpmovemirrors工具会验证该输入文件、调用gp_recoverseg 来重定位每一个指定的镜像，并且移除原始的镜像。它会创建一个撤销配置文件，该文件可以被用作 gpmovemirrors的输入来撤销所作的更改。撤销文件和输入文件同名，但会增加后缀 _backout_timestamp。
关于gpmovemirrors工具的完整信息请见Greenplum数据库管理工具参考。
Master镜像
在一个高可用集群中，有两种master实例，primary和standby。像segment一样，master和standby 应该部署在不同的主机上，以保证集群不出现单节点故障问题。客户端只能连接到primary master并在上面执行查询。 standby master采用基于预写日志（WAL）流复制的方式保持与primary master的数据一致。详情请见Master镜像概述.
如果master故障了，管理员可以通过运行gpactivatestandby工具切换standby master成为 新的primary master。可以通过在master和standby上配置一个虚拟IP地址来保证当发生切换后，客户端不需要在 不同的网址之间切换。如果master主机故障，虚拟IP可以漂移到新的活动master节点上继续提供服务。
Greenplum数据库的master实例是客户端访问系统的唯一入口。master实例存储全局系统目录，也就是存储有关 数据库实例的元数据的一系列系统表，但是它不存储用户数据。如果未配置镜像的master实例故障或不可访问，会 直接导致Greenplum数据库离线，不能正常提供服务。因此，必须配置备用master实例以防止主master故障。
Master镜像使用两个进程使镜像实例与master同步，一个sender位于活动master主机上，一个receiver位于 镜像主机上。随着客户端操作的变化数据被应用到master系统目录上，活动master会将预写日志（WAL）以流复制 的方式应用到备用master节点，以保证每一个应用到master实例的事务也同时应用到了备用master上。
镜像是一个温备。如果主master失效，要切换到备用master需要管理员用户在备用主机上运行 gpactivatestandby工具，这样它才会开始接受客户端连接。客户端此时必须重新连接到新 master，该客户端在主master故障时未提交的事务都会丢失。
Master镜像概述
可以在单独的主机或者同一台主机上部署Master实例的一个备份或者镜像。当主Master变得无法使用时，备份 Master或者后备Master会作为一个温备提供服务。可在主Master在线时从中创建一个后备Master。
在取一个主Master实例的事务快照时，主Master会继续为用户提供服务。在取事务快照以及在后备Master上部署 事务快照时，对主Master的更改也会被记录。在该快照被部署在后备Master上之后，那些更新会被部署以同步后备 Master和主Master。当镜像Master快照部署完成后，变化会应用，二者之间会通过基于WAL日志的流复制的方式 保持同步。Greenplum WAL复制通过walsender和walreceiver 复制进程保持同步。walsender是主master的进程。walreceiver 是standby master的进程。
Figure 1. Greenplum数据库中的Master镜像
由于Master不保存用户数据，只有系统目录表被在主Master和后备Master之间同步。当这些表被更新时，复制日志 会捕获变化并流向standby master以保持与其主master的同步。WAL复制期间，所有的数据库更改在应用之前都 会写入复制日志，以保证任何正在进行的操作的数据完整性。
以下是Greenplum数据库如何处理Master故障
- 如果主master故障，Greenplum数据库系统关闭，master复制进程停止。管理员运行 gpactivatestandby命令将standby master提升为主master。 随着standby master提升为主，复制日志会重建主master最后成功提交的事务的相关日志。 活动standby master接下来会完全成为Greenplum数据库的master，以standby master初始化 时定义的端口号接受外部连接。详情请见恢复故障的Master。
- 如果在主master可用时，standby master故障或不可访问。主master会将数据库变化写入追踪日志， 然后等待standby master恢复后应用到其上面。
以下这些Greenplum系统表包含镜像和复制相关信息。
- 系统表gp_segment_configuration包含主segment、镜像segment、主master和standby master实例的当前配置 及状态信息。
- 系统视图gp_stat_replication包含Greenplum数据库master和segment镜像用到的walsender 进程的复制统计信息。
最佳实践
- 设置一个备用master实例—镜像—在主master故障时接手工作。
- 备用实例可以位于主实例同一或者不同主机上，但是最佳实践是把它放在不同于主master的不同主机上，这样 可以防止主机故障。
- 规划好当故障发生时如何把客户端切换到新的master实例，例如通过更新DNS中的master地址。
- 设置监控，当主Master故障时在系统监控应用中发送通知或者通过邮件通知。
双集群
可以通过维护两套Greenplum数据库集群，都存储相同的数据来提供额外的冗余。
保持双集群数据同步有两种方法，分别叫做”双ETL”和”备份/恢复”。
双ETL提供一个与主集群数据一致的热备份集群。ETL（抽取，转换和加载）大致的过程为清理数据，转换数据，验证数据 和加载数据进入数据仓库。双ETL的方式，以上过程会被执行两次，每个集群一次，每次都需要被验证。这允许在两个集群 上进行查询数据操作，还可以提高查询的吞吐量为原来的两倍。应用可以有效的利用两套集群的优势，页可以确保ETL 成功进行并在两套集群上验证通过。
通过备份/恢复的方法来维护一个双集群，可以直接采用在主集群上创建备份，然后恢复到第二个集群上。该方法可能会比 双ETL的方式花费更多的时间来同步数据，但是对应用端特定业务逻辑开发的要求几乎没有。双ETL的优势是同步频率上更 快，时间间隔更小。
对于一些用例，可以通过维护两个存储同样数据的Greenplum数据库集群提供额外层次的冗余。实现双集群的决定 应该考虑到业务需求。
在双集群配置中为了保持数据同步，有两种推荐方法。第一种方法被称作双ETL。ETL（抽取、转换和装载）是常见 的清理、转换、验证并且将数据装载到数据仓库中的常见数据仓库处理。通过双ETL，ETL处理会被以并行的方式执行 两次，每个集群上一次，并且每一次都会做验证。双ETL提供了一个存有相同数据的备用集群。它还提供了在两个集群 上查询数据的能力，并使得处理吞吐量翻倍。应用可以根据需要利用两个集群，还要确保ETL在两边都成功并且被验证。
维护双集群的第二种机制是备份和恢复。数据在主集群上被备份，然后备份被复制到第二个集群并且在其上恢复。 备份和恢复机制比双ETL的延迟更高，但是需要开发的应用逻辑更少。对于按每天或者更低频率进行数据修改和ETL的 用例，备份和恢复是理想的方案。
最佳实践
- 为了提供额外级别的冗余和额外的查询处理吞吐量，可以考虑双集群配置。
备份和恢复
建议经常备份数据库，可以保证一旦出现问题可以很容易的重新生成数据库集群。备份可以很好的保护 误操作、软件错误和硬件错误。
使用gpbackup工具备份Greenplum数据库。gpbackup在所有segment上执行并行备份， 所以备份能力随着硬件增加线性扩展。
当我们设计备份策略时，最主要的关注点是将数据存储在哪里。数据可以备份在每个segment各自的本地存储中， 但是存储在该位置会导致正常segment可用生产空间锐减，更重要的是，硬件失败可能会摧毁活动segment的 生产数据和备份数据。执行完备份后，备份文件应该从主集群移动到独立、安全的存储位置。另外，备份可以直接 存储在独立存储中。
采用gpbackup和gprestore工具，可以从一个远程位置或存储设备 发送/读取备份。目前该存储插件支持连接到Amazon S3存储服务和Dell EMC Data Domain存储设备。
采用备份/恢复存储扩展API，您可以创建gpbackup和gprestore 工具可用的定制化插件，用来集成您的存储系统到Greenplum数据库。
更多如何使用gpbackup和gprestore的信息，请见 使用gpbackup和gprestore并行备份。
推荐为Greenplum数据库进行备份，除非数据库中的数据可以很容易并且很干净地从源数据再生。备份可以防止操作 错误、软件错误或者硬件错误。
gpbackup工具在segment之间并行地做备份，因此随着集群的硬件尺寸增长备份的尺度也会放大。
备份策略必须考虑备份将被写到什么地方以及它们将被存放在哪里。备份可以放置在本地集群的磁盘上，但是它们不应该 被永久存放在那里。如果数据库及其备份在同一种存储上，它们可能会同时丢失。备份还占据数据库存储或者操作所需的 空间。在执行本地备份后，备份文件应该被拷贝到一个安全的、集群外的位置。
另一种策略是直接备份到一个NFS挂载存储上。如果集群中的每台主机都有一个NFS挂载，备份可以被直接写到NFS存储上。 推荐使用一种可扩展的NFS方案以确保备份不会受到NFS设备的IO吞吐瓶颈限制。Dell EMC Isilon是这类方案的一个例子， 并且可以与Greenplum集群一同扩展。
最后，通过本地API集成，Greenplum数据库可以把备份直接流式传送到Dell EMC Data Domain或者Veritas NetBackup 企业级备份平台。
最佳实践
- 定期备份Greenplum数据库，除非能很容易地从源数据恢复数据。
- 使用gpbackup备份您想要备份的模式和表。更多信息请见gpbackupGreenplum数据库工具参考指南中 的对应部分。
- gpbackup在要备份的表上放置SHARED ACCESS锁。拥有很少表的备份在选择恢复 模式和表时更有效，因为gprestore可以搜索整个数据库。
- 如果备份被保存在本地存储，当备份完成后将备份文件移动到一个安全且非集群存储的位置。备份文件和 数据库文件存储在一起很容易一起丢失。
- 如果备份被保存到NFS挂在存储上，请选用可扩展的NFS解决方案来防止IO瓶颈，例如Dell EMC Isilon。
参考
https://www.bookstack.cn/read/greenplum-admin_guide-6.0-zh/e27c37abeae5aa55.md
https://www.bookstack.cn/read/greenplum-admin_guide-6.0-zh/47bfcbeb07195f4b.md
