Greenplum集群具有较好的容错性和高可用性，其中一点就体现在segment镜像机制上。接下来本文会简单地阐述segment的作用以及segment镜像机制是如何保证GP高可用的。

Segment简介

Greenplum集群由一个Master和多个segment组成

segment用来存储数据

一台机器可以有多个segment

每个segment是一个postgres数据库实例

当Greenplum启用镜像时，对每个segment都有一对primary segment和mirror segment。 primary segment和mirror  segment被分布在不同的机器上，但是存储的是同一份数据。

Segment故障切换

当Greenplum集群启用镜像后，如果primary segment不可用，系统会启用备用mirror segment。所以当一个或多个segment出现问题时，只要剩余segment的所有数据可用，Greenplum集群就可以保持正常运行。如果GP集群没有启用镜像，当一个segment发生故障后后导致整个GP集群停止服务，直到所有segment恢复正常。

如果Master节点无法连接到一个segment，Master会在GP系统目录中标记该segment状态为宕机，并且启用镜像数据。

Segment故障检测

在Master主机上，Postgres的主进程postmaster会派生一个子进程ftsprobe(FTS)用于故障探测。如果FTS失败，postmaster会重启它。FTS会按照 数据库 配置周期性的请求各segment，并扫描segment的状态。

如果FTS无法连接到某个segment，它会在数据库系统目录标记该segment的状态为”down”。该segment在这期间无法被操作，直到进行恢复处理。

FTS配置参数：

gp_fts_probe_threadcount

– 探测Segment的线程数。默认值：16

gp_fts_probe_retries

– 尝试探测一个Segment的次数。例如如果该设置是   5，在第一次尝试失   败后将会有4次重试。默认值：5

gp_fts_probe_timeout

– 在Master和Segment之间的探测超时时长，以秒计。默认值：20，最大     值：3600。

gp_fts_probe_interval

– 多长时间开始一次新的FTS循环，以秒计。例如如果设置是60并且探测     循环本身需要10秒，FTS处理会睡眠50秒。如果该设置是60并且探测循     环需要75秒，FTS进程睡眠0秒。默认值：60，最大值：3600。

gp_log_fts

– FTS的日志级别。off、terse、verbose、debug。verbose可以被用在生产环境中为排查问题提供有用的数据。debug设置不应该被用在生产中。默认值：terse。

gp_segment_connect_timeout

– 允许一个镜像做出响应的最大时间（以秒计）。默认值：180

FTS会通过向segment数据库建立一个TCP连接来探测每一个primary segment数据库，连接时使用注册在gp_segment_configuration表中的主机名和端口。

注册在gp_segment_configuration表中的主机名和端口如下图：

如果连接成功，segment会执行一些简单的检查并返回结果给FTS。这些检查包括对关键的segment目录上执行一次stat以及检查segment的内部故障。如果没有检测到问题，会给FTS一个正常反馈。

源码中的反馈结果包含如下：

如果FTS无法建立连接或者在超时后没有收到一个回复，则会重试。如果失败的探测次数超过配置的最大次数，FTS会探测该segment的镜像是否正常，然后更新gp_segment_configuration表标记primary segment为down，并且设置该镜像作为primary segment运行。FTS会在gp_configuration_history中记录该操作。

当只有一个活动的primary segment并且相应的镜像宕机时，该primary segment会进入到”Change Tracking Mode”。在这种模式中，对该Segment的操作会被记录，这样可以同步镜像而无需把primary segment的完整数据复制给mirror segment。

gprecoverseg命令可以恢复宕机的镜像。

默认情况下，gprecoverseg执行一次增量恢复，把该镜像置于resync模式中，然后开始把primary segment记录的更改在镜像上进行重放。

如果不能完成增量恢复，可以重新以-F选项运行gprecoverseg来执行完全恢复。这种操作会导致primary segment把所有的数据都复制给镜像。

在gp_segment_configuration表中，每个Segment可以有三种模式：

change tracking

resync

synced

同时还可以有”up”或”down”两种状态。

gpcc的监控状态如下图：

gp_segment_configuration表还有两个列role和preferred_role。

role：表示该segment数据库的当前角色

preferred_role：表示该segment的原始角色。

在集群正常时，所有segment的role和preferred_role都是匹配的。当它们不匹配时，每台硬件主机上活动的primary segment数量发生倾斜。为了重新平衡该集群并且让所有的segment回到它们的首选角色，可以用-r选项运行gprecoverseg命令。

 

最后提醒各位Greenplum的使用者，虽然Greenplum有完善的容错机制。但是当GP发生故障，主备segment切换后，会造成负载不均衡，耗费更多的系统资源，同时会大幅度降低查询等操作的效率。所以，及时恢复失败的segment，把所有segment恢复成原有的角色是非常必要的工作。

以上就是本文的全部内容，希望本文的内容对大家的学习或者工作能带来一定的帮助，也希望大家多多支持 码农网

转载自：https://www.codercto.com/a/41959.html