Greenplum中检测和恢复故障的segment

检测故障的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工具来验证重新同步进程的状态：

   本人提供Oracle、MySQL、PG等数据库的培训和考证业务，私聊QQ646634621或微信db_bao，谢谢！
   $ 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重新联机。例如，该命令重新 启动系统。

缺省情况下，将恢复出现故障的Segment，这意味着系统将该Segment重新联机到与最初配置的主机和 数据目录位置相同的位置。在这种情况下，请使用以下格式的恢复配置文件（使用-i）。

在某些情况下，这可能是不可能的（例如，如果主机物理损坏，无法恢复）。gprecoverseg 允许用户将失败的Segment恢复成全新的主机（使用-p），在剩余的活动Segment主机上的 备用数据目录位置（使用-s）或通过以下面的格式提供恢复配置文件（使用-i）。 SPACE关键字表示所需空间的位置。不要添加额外的空间。

有关恢复配置文件的详细信息和示例，请参阅下面的-i选项。

gp_segment_configuration系统目录表可以帮助用户确定当前的Segment配置， 以便用户可以规划镜像恢复配置。例如，运行以下查询：

新恢复的Segment主机必须预先安装Greenplum数据库软件，并且配置与现有Segment主机完全相同。所有 当前配置的Segment主机上必须存在备用数据目录位置，并且有足够的磁盘空间来容纳故障的Segment。

恢复过程会在Greenplum数据库系统目录中再次标记该Segment，然后启动重新同步过程，以使Segment的 事务状态处于最新状态。在重新同步期间系统在线并且可用。要检查重新同步进程运行的状态：

选项

-a（不提示）

不要提示用户确认。

-B parallel_processes

并行恢复的Segment数。如果未指定，则实用程序将启动最多16个并行进程，具体取决于需要恢复 多少个Segment实例。

-d master_data_directory

可选。Master主机的数据目录。如果未指定，则使用为$MASTER_DATA_DIRECTORY 设置的值。

-F（完全恢复）

可选。执行活动Segment实例的完整副本以恢复出现故障的Segment。 默认情况下，仅复制Segment关闭 时发生的增量更改。

Warning: 全量恢复会在从活动（当前主）Segment实例复制数据目录到故障Segment之前将 故障Segment的数据目录清空。在执行全量恢复前，确保Segment故障不会引起数据损坏，并且任何Segment 磁盘故障问题均被修复。

全量恢复会持续很长时间，所以gprecoverseg会显示每个Segment的运行处理过程。 每个Segment的处理过程每秒更新一次，采用ANSI逃逸符更新每一个Segment行，如果您将gprecoverseg 工具执行日志输出到文件或您的终端不支持ANSI逃逸符，可以采用-s选项停用ANSI逃逸符。 该操作会使每个Segment每秒输出一个新行。带有--no-progress时会禁用处理报告。

-i recover_config_file

指定文件的名称以及有关故障Segment要恢复的详细信息。文件中的每一行都是以下格式。SPACE 关键字表示所需空间的位置。不要添加额外的空间。

注释

以#开始的行被视为注释并被忽略。

要恢复的Segments

第一行之后的每一行指定要恢复的Segment。这一行可以有两种格式之一。在就地恢复的情况下， 在该行中输入一组冒号分隔的字段。例如：

要恢复到新位置，请在行中输入由空格分隔的两组字段。SPACE表示不要添加额外的空间。

示例

单个镜像的就地恢复

将单个镜像恢复到新主机

获取示例文件

用户可以使用-o选项输出一个恢复配置文件的样例以便从它开始。

-l logfile_directory

写入日志文件的目录。默认为~/gpAdminLogs。

-o output_recover_config_file

指定文件名称和位置以输出示例恢复配置文件。输出文件以-i选项所需的格式列出当前故障 的Segment及其默认恢复位置。 与-p选项一起使用可输出用于在不同主机上恢复的示例文件。 如果需要，可以编辑此文件以提供备用恢复位置。

-p new_recover_host[,…]

在当前配置的Greenplum数据库阵列之外指定一个备用主机，用于恢复故障的Segment。在多个故障的Segment 主机的情况下，用户可以指定一个逗号分隔的列表。备用主机必须安装和配置Greenplum数据库软件，并具有与当前 网段主机相同的硬件和操作系统配置（相同的OS版本、语言环境、gpadmin用户帐户、创建的 数据目录位置、交换的ssh密钥、网络接口数量、网络接口命名约定等）。

-q（无屏幕输出）

以静默模式运行。命令输出不显示在屏幕上，但仍然写入日志文件。

-r（重新平衡Segment）

在Segment恢复之后，Segment实例可能并未回到系统初始化时为它给定的优先角色。这可能会让系统陷入一种 潜在的非平衡状态，因为某些Segment主机拥有的活动Segment数量可能超过最高系统性能时的数量。这一选项通过 将主Segment和镜像Segment返回到其优先角色来重新平衡主Segment和镜像Segment。在运行gprecoverseg -r 之前，所有的Segment都必须有效且同步。如果有任何正在进行的查询，它们将被取消并回滚。

-s

展示pg_basebackup顺序处理过程而不是当前情况。此选项在需要写入文件或tty 不支持转义字符时有用。默认是展示当前处理过程。

--no-progress

禁用产生于pg_basebackup的处理过程报告。默认配置为显示基础备份的处理过程。

-v（详细模式）

将日志记录输出设置为verbose。

--version（版本）

显示此工具的版本。

-?（帮助）

显示在线帮助。

示例

恢复所有故障的Segment实例：

恢复后，重新平衡用户的Greenplum数据库系统，将所有Segment重置为其首选角色。 首先检查所有Segment已启动并同步。

将任何故障的Segment实例恢复到新配置的空闲Segment主机：

输出默认恢复配置文件：

gprecoverseg修复示例

primary segment节点和mirror segment节点的故障修复方式是一样的

这里以mirror节点故障为例，关闭一个节点后集群状态

mirror故障示例

修复：

其它故障示例

1、primary故障示例

2、节点故障示例（单个或多个节点）

恢复方式都一样，不再演示。

总结

1. 当一个primary segment节点故障，那么它所对应的mirror segment节点会自动接替primary的状态，继续保证整个集群的数据完整性

2. 当一个mirror segment节点出现故障，它不会影响整个集群的可用性，但是需要尽快修复，保证所有的primary segment都有备份

3. 如果primary segment 和它所对应的mirror segment 节点都出现故障，那么greenplum认为集群数据不完整，整个集群将不再提供服务，直到primary segment 或 mirror segment恢复

4. primary segment节点和mirror segment节点的故障修复方式是一样的，都执行如下命令即可：gprecoverseg -a

   恢复方式都一样，若没有业务连接，则可以直接进行恢复：

   -- 恢复segment gprecoverseg -a -- 重平衡回到最初状态 gprecoverseg -r

   1 2 3 4 5

   -- 恢复segment gprecoverseg -a   -- 重平衡回到最初状态 gprecoverseg -r

   若有业务连接，则需要关闭和重启集群：

   -- 关闭集群 gpstop -a -M fast -- 以restricted方式启动数据库 gpstart -a -R -- 修复集群 gprecoverseg -a -- 检测状态（一直等到Data Status 这个属性全部都是Synchronized即可进行下一步操作） gpstate -m -- 重平衡回到最初状态 gprecoverseg -r -- 重启集群 gpstop -a -r

   1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18

   -- 关闭集群 gpstop -a -M fast   -- 以restricted方式启动数据库 gpstart -a -R   -- 修复集群 gprecoverseg -a   -- 检测状态（一直等到Data Status 这个属性全部都是Synchronized即可进行下一步操作） gpstate -m   -- 重平衡回到最初状态 gprecoverseg -r   -- 重启集群 gpstop -a -r

5. 在执行gprecoverseg恢复segment后，原有的primary和mirror会发生变动，可能导致所有的primary都在同一台几点，会导致性能问题，所以应该执行命令进行重平衡gprecoverseg -r就可以让集群回到最初的配置角色了。

参考

https://www.bookstack.cn/read/greenplum-admin_guide-6.0-zh/def8a6062e8513c1.md

https://www.bookstack.cn/read/greenplum-admin_guide-6.0-zh/35facabf06f3da24.md