合 Greenplum中检测和恢复故障的segment（gprecoverseg）

检测故障的Segment

如果启用了镜像，Greenplum数据库会在主Segment宕机后自动故障转移到一个镜像Segment上，镜像Segment承担主Segment的角色和职能，故障主Segment变成镜像，用户感觉不到segment产生了故障。

当故障出现时，正在进行中的事务会回滚并在新的segment上自动重新开始。

gpstate工具可以用来分辨故障segment。该工具显示的系统表信息包括gp_segment_configuration。

如果整个Greenplum数据库系统由于一个Segment故障（例如，如果没有启用镜像或者没有足够的Segment在线 以访问全部用户数据）而变得无法运转，用户在尝试连接到数据库时会看到错误。返回给客户端程序的错误可能表明 失效。例如：

segment故障如何被监测和管理

在Greenplum数据库master主机上，Postgres的postmaster进程会创建一个错误侦测子进程 ftsprobe。该进程也被称为FTS (Fault Tolerance Server)进程。如果FTS进程出现故障， postmaster会重启该进程。

FTS进程循环执行，每个循环之间会停顿一会。每一个循环中，FTS都会从gp_segment_configuration 系统表中获取每一个主segment实例的主机名和端口号，并通过与其建立TCP套接字连接的方式连接segment实例 来侦测segment的状态。如果成功连接，segment会执行一些简单的检查并报告给FTS。该检查包括在关键的segment 目录上执行一个stat系统调用，并且会检查segment实例的内部错误。如果没有检测到问题，FTS会 收到一个积极的反馈信号，被检查的正常segment也不会采取任何附加操作。

如果不能建立连接，或者在超时时间内没有得到反馈，FTS会尝试重新连接segment实例。 如果达到了FTS的最大重试次数，FTS会去检测该segment的镜像看其是否在线，如果在线它就会修改 gp_segment_configuration表，将原来的主segment标记为”down”并设置 镜像承担主segment的角色。FTS会把执行过的操作更新到 gp_configuration_history表中。

当系统中只有主segment正常，其对应的镜像故障时，主segment会进入not synchronizing 状态并继续记录数据库日志变化，一旦镜像修复，便可以将这些变化继续同步，而不用从主segment执行一个完整的拷贝。

运行gpstate工具并带有-e选项可以展示单个主segment和镜像segment实例 的任何问题。gpstate的另外一些选项也能显示所有主segment或镜像segment实例的信息，例如 -m（镜像实例信息）、-c（主segment和镜像segment配置信息），另外也可以 显示主segment和镜像segment的问题。

您也可以从系统表gp_segment_configuration查看当前模式： s (同步状态)n (非同步状态)，还有当前状态 u (在线) or d (离线)。

gprecoverseg工具可以用于将离线的镜像segment重新加入集群。默认情况下， gprecoverseg会执行增量恢复，首先将镜像放入同步模式，接下来会重放主segment上 记录下来的日志变化到镜像segment。如果增量恢复失败，整个恢复便会失败。此时可以执行gprecoverseg 并带有-F选项，以执行一个全量恢复，该操作会复制主segment上的所有数据到镜像segment上。

segment实例恢复后，gpstate -e命令可以列出所有切换了的主segment和镜像segment实例信息。 该信息表示系统目前处于不均衡状态（主实例和镜像实例不在他们的初始配置角色）。如果系统目前处于不均衡状态，在segment 主机系统上可能存在活动主segment实例分布不均匀的结果。

系统表gp_segment_configuration包含列role和 preferred_role。该列上的值为p代表主segment，m 代表镜像segment。role列展示segment实例当前角色，preferred_role 列展示segment实例原来的角色。

在一个平衡的系统中，所有segment实例的role和preferred_role 列都是对应一致的。当某一个列存在不一样的情况时，表明系统是不平衡的。为了重新平衡集群并将所有的segment恢复到他们 本来的角色，可以运行gprecoverseg命令并带有-r选项。

简单的故障转移和恢复示例

本例子已经假设一个单独的主-镜像segment实例对中主segment故障并切换到镜像segment。 以下表格展示在恢复到正常的主segment之前，segment实例在gp_segment_configuration 表中的本来角色, 当前角色, 模式, 和状态：

也可以通过执行gpstate -e来显示主segment和镜像segment的状态信息

segment实例不在他们原来的最佳角色，主segment故障。镜像segment上线成为主segment，目前为非同步模式， 因为他的镜像（之前失败的主segment）处于故障状态。当修复了故障问题后，使用gprecoverseg 重新将失败的实例拉起并在主segment和镜像segment之间同步差异数据。

一旦gprecoverseg操作完成，segment的状态如下表展示，主segment和镜像segment 转换成为他们之前的最佳角色。

gprecoverseg -r命令通过将segment的角色切换回他们之前的最佳角色来重新平衡 整个集群系统。

配置FTS行为

有一系列的服务器配置参数会影响FTS行为：

gp_fts_probe_interval

开始下一个FTS循环的时间间隔，以秒为单位。例如将该参数设置为60，检测循环持续10秒，那么FTS进程 沉睡50秒。如果设置该参数为60，检测循环持续75秒，FTS进程沉睡0秒。该参数默认值为60，最大为3600。

gp_fts_probe_timeout

master到segment之间的检测超时时间，以秒为单位。默认20秒，最大3600秒。

gp_fts_probe_retries

检测segment失败后的重试次数，例如如果设置为5，那么首次失败后，会再进行4次检测尝试。默认为5。

gp_log_fts

FTS日志级别。可设置的值有：”off”, “terse”, “verbose”, or “debug”。 “verbose”设置可以用在生产上，能为问题定位提供一些有用的数据。”debug” 设置不能用在生产上。默认为：”terse”。

gp_segment_connect_timeout

允许镜像响应的最大时间，以秒为单位。默认为：600（10分钟）

除了可以使用FTS执行错误检查外，不能发送数据到其镜像segment的主segment可以改变镜像的状态为down。 主segment会将同步数据暂时排队处理，如果gp_segment_connect_timeout时间超时， 此时意味着镜像故障，系统会标记镜像为down并将主segment变为变化追踪（change tracking）模式。

检测故障Segment

启用镜像的情况下，系统允许存在故障Segment并且不影响数据库服务正常运行。可以通过 gpstate工具查看整个数据库系统状态。gpstate 可以展示整个数据库系统中包括主Segment、镜像Segment、Master和备用Master在内的每 一个单独系统组件的状态。

如何检测故障Segment

1. 在Master上，用-e选项运行gpstate工具显示有错误情况的Segment：

   $ gpstate -e

   1	$ gpstate -e

   如果工具列出Segments with Primary and Mirror Roles Switched，表明 segment不在他的原始角色（系统初始化时赋予的角色）。这意味着系统处于一种潜在的不平衡状态， 因为一些segment主机可能比正常状态下拥有更多的活动segment，并不处于它们的最佳性能状态。

   Segments展示Config status为Down则预示着 其对应的镜像segment产生故障下线了。

   修复该问题的详细过程，请见从Segment故障中恢复。

2. 为了获取故障segment的详细信息，可以检查 gp_segment_configuration系统表。例如：

   $ psql postgres -c "SELECT * FROM gp_segment_configuration WHERE status='d';"

   1	$ psql postgres -c "SELECT * FROM gp_segment_configuration WHERE status='d';"

3. 针对那些故障的segment实例，注意主机、端口号、原来角色和数据目录。这些信息会帮助您在问题定位时 提供有用的决策信息。

4. 要展示镜像segment实例的信息，运行：

   gpstate -m

   1	gpstate -m

检查日志文件

日志文件可以提供信息来帮助判断一个错误的成因。每个Master和Segment实例都在其数据目录的 pg_log中有它们自己的日志文件。Master的日志文件包含了大部分信息，应该总是首先检查它。

gplogfilter工具可以用来检查Greenplum数据库日志文件。 如果要检查segment日志文件，使用gpssh在segment主机上执行gplogfilter工具。

如何检查日志文件

1. 对于WARNING、ERROR、FATAL或 PANIC日志级别的消息，使用gplogfilter检查Master的日志文件：

   $ gplogfilter -t

   1	$ gplogfilter -t

2. 对于每个Segment实例上的WARNING、ERROR、 FATAL或PANIC日志级别的消息，使用gpssh检查。例如：

   $ gpssh -f seg_hosts_file -e 'source /usr/local/greenplum-db/greenplum_path.sh ; gplogfilter -t /data1/primary/*/pg_log/gpdb*.log' > seglog.out

   1	$ 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实例的故障原因多种多样：

• Segment主机不可用，例如由于网络或者硬件失效。
• Segment实例没有运行，例如没有postgres数据监听器进程。
• Segment实例的数据目录损坏或者丢失，例如数据不可访问、文件系统损坏或者磁盘失效。

Figure 1展示了前述失效场景的高层排查步骤。

Figure 1. Segment失效故障排查矩阵

从Segment故障中恢复

Segment主机故障通常会导致多个Segment故障：在该主机上的所有主Segment或者镜像Segment都被标记为“down” 并且不可操作。如果没有启用镜像并且一个Segment宕掉，系统会自动变成不可操作。

segment实例可能会因为很多原因产生故障。例如主机故障，网络故障或磁盘故障。当segment实例故障时，它的 状态在系统表中被标记为down，它的镜像切换到change tracking模式。为了将故障segment实例 修复并重新进入可操作状态，您必须首先修复导致故障的问题，然后使用gprecoverseg工具 恢复该故障实例。

如果一台segment主机不可恢复，此时您已经失去了一个或多个segment实例，那么您可以尝试从它的镜像segment 来恢复该segment实例。详见当一台Segment主机不可恢复时。 您也可以从备份文件重新创建Greenplum数据库。详见备份和恢复数据库。

在启用了镜像的情况下恢复

1. 确保可以从Master主机连接到该Segment主机。例如：

   $ ping failed_seg_host_address

   1	$ ping failed_seg_host_address

2. 排查解决妨碍Master主机连接到Segment主机的问题。例如，主机可能需要被重启或者替换。

3. 在主机上线并且能连接到它后，从Master主机运行gprecoverseg工具来重新激活故障的Segment实例。 例如：

   $ gprecoverseg

   1	$ gprecoverseg

4. 恢复过程会启动失效的Segment并且确定需要同步的已更改文件。该过程可能会花一些时间， 请等待该过程结束。在此过程中，数据库的写活动会被禁止。

5. 在gprecoverseg完成后，系统会进入到Resynchronizing 模式并且开始复制更改过的文件。这个过程在后台运行，而系统处于在线状态并且能够接受数据库请求。

6. 当重新同步过程完成时，系统状态是Synchronized。运行gpstate工具来验证重新同步进程的状态：

   $ gpstate -m

   1	$ gpstate -m

要让所有Segment返回到它们的首选角色

当一个主Segment宕掉后，镜像会激活并且成为主Segment。在运行gprecoverseg之后， 当前活动的Segment仍是主Segment而失效的Segment变成镜像Segment。这些Segment实例并没有回到在系统 初始化时为它们指定的首选角色。这意味着，如果Segment主机上的活动Segment数量超过了让系统性能最优的 数量，系统可能处于一种潜在地非平衡状态。要检查非平衡的Segment并且重新平衡系统，运行：

所有Segment都必须在线并且被完全同步以重新平衡系统。在重新平衡过程中，数据库会话保持连接，但正在 进行的查询会被取消并且回滚。

1. 运行gpstate -m来确保所有镜像都是 Synchronized。

   $ gpstate -m

   1	$ gpstate -m

2. 如果有任何镜像处于Resynchronizing模式，等它们完成。

3. 运行gprecoverseg工具并带有-r选项， 让Segment回到它们的首选角色。

   $ gprecoverseg -r

   1	$ gprecoverseg -r

4. 在重新平衡之后，运行gpstate -e来确认所有的Segment都处于 它们的首选角色。

   $ gpstate -e

   1	$ gpstate -e

从双重故障中恢复

在双重故障中，主Segment和它的镜像都宕掉。如果在不同的Segment主机上同时发生硬件失效，就有可能发生 这种情况。

如果发生双重故障，Greenplum数据库会变得不可用。

从一次双重故障中恢复的步骤如下：

从双重故障中恢复

1. 处理引起双重故障的问题原因并解决，确保segment主机可操作并且可以从master主机访问。

2. 重启Greenplum数据库。gpstop工具带有-r参数执行时，会停止并重新启动Greenplum 数据库系统。

   $ gpstop -r

   1	$ gpstop -r

3. 在系统重启后，运行gprecoverseg重新激活故障segment实例：

   $ gprecoverseg

   1	$ gprecoverseg

4. 在gprecoverseg完成后，使用 gpstate检查所有镜像状态，确保segment实例的状态从Resynchronizing 模式变成模式：

   $ gpstate -m

   1	$ gpstate -m

5. 如果仍有Segment处于change tracking模式，运行gprecoverseg 并带有-F选项执行一次完整恢复。

   Warning: 一个完整的恢复会在从活动segment实例（当前主实例）复制数据前， 删除离线segment实例的数据目录。在执行全量恢复前，确保segment失败不会引起数据损坏， 任何主机的segment磁盘问题都已经被修复。

   $ gprecoverseg -F

   1	$ gprecoverseg -F

6. 如果需要，将segment实例的角色恢复到它们的最佳角色。详见要让所有Segment返回到它们的首选角色。

在没有启用镜像的情况下恢复

1. 确保能够从Master主机连接到该Segment主机。例如：

   $ ping failed_seg_host_address

   1	$ ping failed_seg_host_address

2. 排查解决妨碍Master主机连接到Segment主机的问题。例如，主机可能需要被重新启动。

3. 在主机在线之后，验证能够连接到它并且重启Greenplum数据库。 gpstop带有-r选项可以停止并重启系统：

   $ gpstop -r

   1	$ gpstop -r

4. 运行gpstate工具来验证所有的实例都在线：

   $ gpstate

   1

   $ gpstate

• 当一台Segment主机不可恢复时

当一台Segment主机不可恢复时

如果一台主机是不可操作的（例如由于硬件失效导致），就需要把那些Segment恢复到备用的硬件资源上。 如果启用了镜像，可以使用gprecoverseg工具从segment的镜像把它恢复到另一台主机上。例如：

其中recover_config_file的格式是：

例如，要恢复到不同于失效主机的另一主机上且该没有额外的文件空间配置， (除默认的pg_system文件空间外）：

有关创建segment实例恢复文件的详细信息，请见gprecoverseg。

新恢复的Segment主机必须预装好Greenplum数据库软件并且按照现有Segment主机相同的方式配置。

gprecoverseg命令详解

恢复已标记为down的主Segment实例或镜像Segment实例（如果启用了镜像）。

概要

描述

在启用了镜像的系统中，gprecoverseg工具会重新激活故障的Segment实例， 并识别需要重新同步的已更改的数据库文件。一旦gprecoverseg完成这个过程， 系统进入resyncronizing模式，直到被恢复的Segment更新为最新为止。在重新同步期间 系统处于在线状态并且能被正常操作。

在增量恢复期间（未指定-F选项），如果gprecoverseg 在启用了镜像的系统中检测到禁用镜像的Segment实例，则工具将报告该Segment禁用了镜像，不会尝 试恢复该Segment实例，并继续恢复过程。

Segment实例可能由于多种原因故障，如主机故障、网络故障或磁盘故障。当一个Segment实例故障时， 其状态在Greenplum数据库系统目录中被标记为down并且在change tracking模式 下激活其镜像。为了使发生故障的Segment实例重新运行，首先必须纠正使其故障的问题，然后使用 gprecoverseg在Greenplum数据库中恢复Segment实例。

使用gprecoverseg进行Segment恢复需要有一个活动镜像来从其中恢复。对于 没有启用镜像的系统，或者在发生双重故障的情况下（主Segment和镜像Segment同时故障），必须采取 手动步骤恢复出现故障的Segment实例，然后执行系统重新启动让Segment重新联机。例如，该命令重新 启动系统。

后续精彩内容已被站长无情隐藏，请输入验证码解锁本文！

验证码：

获取验证码： 请先关注本站微信公众号，然后回复“验证码”，获取验证码。在微信里搜索“AiDBA”或者“dbaup6”或者微信扫描右侧二维码都可以关注本站微信公众号。