Greenplum集群主要包括Master节点和Segment节点，Master节点称之为主节点，Segment节点称之为数据节点。Master节点与Segment节点都是可以有备份的，其中Master节点的备节点为Standby Master(不能够自动故障转移)，Segment是通过Primary Segment与Mirror Segment进行容错的。通过本文你可以了解：
- Greenplum数据库的高可用(HA)原理
- Greenplum生产集群中master节点故障恢复
- Greenplum生产集群中segment故障检测与恢复
- Segment节点故障恢复原理与实践
Greenplum数据库的高可用原理
1. master 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服务器和standby master服务器同步后，standbymaster服务器将通过walsender 和 walreceiver 的复制进程保持最新状态。该walreceiver是standby master上的进程， walsender流程是primary master上的进程。这两个进程使用基于预读日志（WAL）的流复制来保持primary master和standby master服务器同步。在WAL日志记录中，所有修改都会在应用生效之前写入日志，以确保任何进程内操作的数据完整性。
由于primary master不包含任何用户数据，因此只需要在主master和standby master之间同步系统目录表(catalog tables)。当这些表发生更新时，更改的结果会自动复制到备用master上，以确保与主master同步。
如果primary master发生故障，管理员需要使用gpactivatestandby工具激活standby master。可以为primary master和standby master配置一个虚拟IP地址，这样，在primary master出现故障时，客户端程序就不用切换到其他的网络地址，因为在master出现故障时，虚拟IP地址可以交换到充当primary master的主机上。
2. mirror segment概述
当启用Greenplum数据库高可用性时，有两种类型的segment：primary和mirror。每个主segment具有一个对应的mirror segment。主segment接收来自master的请求以更改主segment的数据库，然后将这些更改复制到相应的mirror segment上。如果主segment不可用，则数据库查询将故障转移到mirror segment上。
Primary segment和Mirror segment之间的同步与primary master和standby master相同，也是采用基于WAL流的同步。
3. 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配置。
4. Spread mirroring方式
Spread mirroring方式是指将每个主机的mirror segment分布在多个主机上，这样，如果任何单个主机发生故障，该主机的mirror segment会分散到其他多个主机上运行，从而达到负载均衡的效果。仅当主机数量多于每个主机的segment数时，才可以使用Spread方式。下图说明了Spread mirroring方式。
Master节点故障恢复
如果primary master节点失败，日志复制进程就会停止。可以使用gpstate -f命令查看standby master的状态，使用gpactivatestandby命令激活standby master。
1. 激活Standby master
(1)确保原来的集群中配置了standby master
(2)确保primary master已经停止运行，如果primary master仍在运行，提升standby master后，系统可能会有2个primary master，造成数据不一致
(3)在standby master主机上运行gpactivatestandby命令
$ gpactivatestandby -d /data/master/gpseg-1
-d参数是指standby master的数据目录，一旦激活成功，原来的standby master就成为了primary master。
(4)执行激活命令后，运行gpstate命令检查状态
$ gpstate -f新激活的master的状态是active，如果已经为集群配置一个新的standby master节点，则其状态会是passive。如果还没有为集群配置一个新的standby master，则会看到下面的信息：No entries found，该信息表明尚未配置standby master。
(5)在成功切换到了standbymaster之后，运行ANALYZE命令，收集该数据库的统计信息
$ psql postgres -c 'ANALYZE;'(6)可选：如果在成功激活standby master之后，尚未指定新的standby master，可以在active master上运行gpinitstandby命令，配置一个新的standby master
$ gpinitstandby -s new_standby_master_hostname -P <port> -S <standby_master_datadir>2. 恢复到原来的设置(可选的)
(1)确保之前的master节点能够正常使用
(2)在原来的master主机上，移除(备份)原来的数据目录gpseg-1,比如：
$ mv /data/master/gpseg-1 /data/master/backup_gpseg-1(3)在原来的master节点上，初始化standby master，在active master上运行如下命令
$ gpinitstandby -s mdw(4)初始化完成之后，检查standby master的状态
$ gpstate -f显示的状态应该是--Sync state: sync
(5)在active master节点上运行下面的命令，用于停止master
$ gpstop -m(6)在原来的master节点(mdw)上运行gpactivatestandby命令
$ gpactivatestandby -d /data/master/gpseg-1(7)在上述命名运行结束之后，再运行gpstate命令查看状态
$ gpstate -f确认原始的primary master状态是active。
(8)在原来的standby master节点(smdw)上，移除(备份)数据目录gpseg-1
$ mv /data/master/gpseg-1 /data/master/backup_gpseg-1(9)原来的master节点正常运行之后，在该节点上执行如下命令，用于激活standby master
$ gpinitstandby -s smdw -P <port> -S <standby_master_datadir>3. 检查standby master的状态
可以通过查看视图pg_stat_replication，来获取更多的同步信息。该视图可以列出walsender进程的信息，下面的命令是查看walsender进程的进程id和状态信息。
$ psql postgres -c 'SELECT pid, state FROM pg_stat_replication;'Segment节点故障检测与恢复
1. 概述
Greenplum数据库主节点服务器上，postmas进程有一个子进程ftsprobe，它的主要作用是处理segment节点的故障检测和提升。ftsprobe 监视Greenplum数据库segments节点，它周期性地扫描所有segment节点。如果 ftsprobe无法连接到segment，它会在Greenplum数据库系统目录中将segment标记为”down”。在管理员启动恢复进程之前，该segment是不可以被操作的。
启用mirror备份后，如果primary segment不可用，Greenplum数据库会自动故障转移到mirror segment。如果segment实例或主机发生故障，系统仍可以运行，前提是所有在剩余的活动segment上数据都可用。
要恢复失败的segment，管理员需要执行 gprecoverseg 恢复工具。此工具可以找到失败的segment，验证它们是否有效，并将事务状态与当前活动的segment进行比较，以确定在segment脱机时所做的更改。gprecoverseg将更改的数据库文件与活动segment同步，并使该segment重新上线。管理员需要在在Greenplum数据库启动并运行时执行恢复操作。
禁用mirror备份时，如果segment实例失败，系统将变得几乎不可用。管理员需要手动恢复所有失败的segment。
2. 检测和管理失败的segment
使用工具命令查看
启用mirror备份后，当primary segment发生故障时，Greenplum会自动故障转移到mirror segment。如果每个数据部分所在的segment实例都是在线的，则用户可能无法意识到segment已经出现故障。如果在发生故障时正在进行事务（还未进入两阶段提交的第二阶段），则正在进行的事务将被回滚。
如果整个Greenplum数据库系统由于segment故障而变得不可访问（例如，如果未启用mirror备份或没有足够的segment在线），则用户在尝试连接数据库时将看到错误。返回到客户端程序的错误可能表示失败。例如：
ERROR: failed to acquire resources on one or more segments在master节点上，运行gpstate命令，使用-e参数显示错误的segment
$ gpstate -e
值得注意的是，即便是一组primary和mirror都发生了故障（double failure），在gp_segment_configuration中也只会有一个的status显示为’d'。这是因为mirror发生故障时，ftsprobe不会再向primary进行探测了，进而不会将剩下的节点标记为’d’。在进行query派发的时候，由于创建interconnect失败，QD进程向用户返回错误。
检查日志文件
日志文件可以提供信息以帮助确定错误的原因。Master实例和segment实例都有自己的日志文件，这些日志文件位于pg_log的目录下。Master的日志文件包含最多信息，应该首先检查它。
使用 gplogfilter工具检查Greenplum数据库日志文件，可以获取额外信息。要检查segment日志文件，可以在master主机上使用gpssh命令运行 gplogfilter。
(1)使用 gplogfilter 检查master日志文件的WARNING, ERROR, FATAL 或者 PANIC日志级别消息
$ gplogfilter -t(2)使用 gpssh 检查每个segment实例上的日志级别为WARNING, ERROR, FATAL 或者 PANIC的消息。例如：
$ gpssh -f seg_hosts_file -e 'source
/usr/local/greenplum-db/greenplum_path.sh ; gplogfilter -t
/data1/primary/*/pg_log/gpdb*.log' > seglog.out恢复失败的segment
如果master服务器无法连接到segment实例，则会在Greenplum数据库系统目录中将该segment标记为“down”状态。在管理员采取措施使segment实例重新上线之前，segment实例将保持脱机离线状态。segment实例可能由于多种原因而不可用：
(1)segment主机不可用; 例如，由于网络或硬件故障。
(2)segment实例未运行; 例如，没Postgres的数据库监听进程。
(3)segment实例的数据目录损坏或丢失; 例如，无法访问数据，文件系统已损坏或磁盘发生故障。
在启用mirror segment的情况下进行恢复
(1)确保master主机能够ping通失败的segment主机
$ ping failed_seg_host_address(2)在master主机上运行下面命令，重新激活失败的segment
$ gprecoverseggprecoverseg的执行过程可能需要一些时间，在此过程中，数据库不允许写入操作。成功执行后，节点会作为备节点来使用。
(3)恢复进程会显示故障segment并标识需要同步的已更改文件。这个过程可能需要一些时间，等待该过程完成。在此过程中，数据库不允许写入操作。
(4)在 gprecoverseg完成后，系统进入重新同步模式并开始复制已更改的文件。当系统处于联机状态并接受数据库请求时，此进程在后台运行。
(5)重新同步过程完成后，系统状态为“已同步”（ Synchronized）。运行gpstate 命令用于验证重新同步过程状态
$ gpstate -m将所有的segment恢复到原来的角色设置
当primary segment发生故障时，mirror segment会被激活为primary segment。运行gprecoverseg命令之后，当前活动的segment是primary segment，失败的primary segment成为了mirror segment。segment实例不会返回到在系统初始化时配置的首选角色。这意味着某些segment主机上可能运行多个primary segment实例，而某些segment主机上运行较少的segment，即系统可能处于潜在的不平衡状态。要检查不平衡的segment，可以使用如下命令：
$ gpstate -e所有segment必须在线并完全同步以重新平衡系统，数据库会话在重新平衡期间保持连接，但正在进行的查询将被取消并回滚。
(1)运行下面命令，查看mirror segment的角色和同步状态
$ gpstate -m(2)如果有mirror segment处于非同步状态，等待他们同步完成
(3)运行gprecoverseg命令，使用-r参数将segment恢复到原来初始化时的角色设置
$ gprecoverseg -r(4)运行gpstate -e命令，确认所有的segment是否恢复到初始化时的角色设置
$ gpstate -e双重故障(double-fault)
在双重故障情况下，即primary segment和mirror segment都处于失败状态。如果不同segment的主机同时发生硬件故障，则会导致primary segment和mirror segment都处于失败状态。如果发生双重故障，Greenplum数据库将不可用。
Segment故障恢复原理与实践
1. Greenplum集群环境介绍
该生产环境集群由四台服务器构成，其中一台为primary master节点，一台为standby master节点，两外两台为segment节点，每个segment节点有四个segment(两个primary segment，两个mirror segment)，segment采用group方式进行备份(sdw1的备份都在sdw2上，sdw2的备份都在sdw1上)，其角色分配如下图所示：
2. segment故障检查
gpstate -m日志信息
gpstate -e 日志信息
gpstate -e 日志信息
gpstate -s 日志信息
(1)sdw1节点的日志信息
(2)sdw2节点的日志信息
3. 故障说明
sdw1节点primary segment正常，mirror segment被激活，其mirror segment为sdw2节点上的primary segment备份。sdw2节点primary segment失败，mirror segment失败。此时集群环境能够正常提供服务，全部负载到sdw1节点上。
使用select * from gp_segment_configuration查看segment角色信息，如下图所示：
4. segment故障恢复
在master主机上运行下面命令，重新激活失败的segment
$ gprecoverseg
运行gpstate 命令用于验证重新同步过程状态
$ gpstate -m
当primary segment发生故障时，mirror segment会被激活为primary segment。运行gprecoverseg命令之后，失败的primary segment成为了mirror segment，而mirror segment被fts probe进程提升成为primary segment。segment实例不会返回到在系统初始化时配置的首选角色。这意味着某些segment主机上可能运行多个primary segment实例，而某些segment主机上运行较少的segment，即系统可能处于潜在的不平衡状态。如下图所示，sdw1上的mirror segment变为了primary segment，sdw2上的primary segment变为了mirror segment。即sdw2的primary segment运行在sdw1节点上，系统处于不平衡状态。
运行gprecoverseg命令，使用-r参数将segment恢复到原来初始化时的角色设置
$ gprecoverseg -r再次查询gp_segment_configuration会发现，所有的 segment都处于up状态，并且它们此时的角色和初始化集群时分配的角色一致。
小结
本文主要介绍了GP的高可用原理及实践。首先介绍了Master与Segment的容错策略，然后介绍了Master节点与Segment节点故障恢复的步骤，最后给出了一个完整的实践过程。
作者简介
原文改编自“大数据技术与数仓”，Greenplum最新版本内容更新自吴昊。
吴昊，Greenplum研发工程师
2018年加入Greenplum团队，参与设计和实现disk quota，并一直从事Greenplum内核研发相关工作，有着丰富的数据库内核开发经验。