Greenplum数据库中segment故障检测

1.Greenplum数据库中segment故障检测

1.1概述

Greenplum数据库服务器（Postgres）有一个子进程，该子进程为ftsprobe，主要作用是处理故障检测。 ftsprobe 监视Greenplum数据库阵列，它以可以配置的间隔连接并扫描所有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。

1.2检测和管理失败的segment

1.2.1使用工具命令查看

启用mirror备份后，当primary segment发生故障时，Greenplum会自动故障转移到mirror segment。如果每个数据部分所在的segment实例都是在线的，则用户可能无法意识到segment已经出现故障。如果在发生故障时正在进行事务，则正在进行的事务将回滚并在重新配置的segment集上自动重新启动。

如果整个Greenplum数据库系统由于segment故障而变得不可访问（例如，如果未启用mirror备份或没有足够的segment在线），则用户在尝试连接数据库时将看到错误。返回到客户端程序的错误可能表示失败。例如：

ERROR: All segment databases are unavailable

(1)在master节点上，运行gpstate命令，使用-e参数显示错误的segment

   标记为Change Tracking的segment节点表明对应的mirror segment已经宕机。

(2)要获取有关故障segment的详细信息，可以查看 gp_segment_configuration目录表。

(3) 对于失败的segment实例，记下主机，端口，初始化时的角色和数据目录。此信息将帮助确定要进行故障排除的主机和segment实例。

(4) 显示mirror segment详细信息，运行下面命名：

1.2.2检查日志文件

日志文件可以提供信息以帮助确定错误的原因。Master实例和segment实例都有自己的日志文件，这些日志文件位于pg_log的目录下。Master的日志文件包含最多信息，应该首先检查它。

使用 gplogfilter工具检查Greenplum数据库日志文件，可以获取额外信息。要检查segment日志文件，可以在master主机上使用gpssh命令运行 gplogfilter。

       (1)使用 gplogfilter 检查master日志文件的WARNING, ERROR, FATAL 或者 PANIC日志级别消息

       (2)使用 gpssh 检查每个segment实例上的日志级别为WARNING, ERROR, FATAL 或者 PANIC的消息。例如：

2.恢复失败的segment

如果master服务器无法连接到segment实例，则会在Greenplum数据库系统目录中将该segment标记为“down”状态。在管理员采取措施使segment实例重新上线之前，segment实例将保持脱机离线状态。segment实例可能由于多种原因而不可用：

(1)segment主机不可用; 例如，由于网络或硬件故障。

(2)segment实例未运行; 例如，没Postgres的数据库监听进程。

(3)segment实例的数据目录损坏或丢失; 例如，无法访问数据，文件系统已损坏或磁盘发生故障。

2.1在启用mirror segment的情况下进行恢复

（1）确保master主机能够ping通失败的segment主机

（2）如果是阻止master主机连接segment主机，则可以重启该segment主机。

（3）如果该segment主机上线之后，可以通过master连接，则在master主机上运行下面命令，重新**失败的segment

（4）恢复进程会显示故障segment并标识需要同步的已更改文件。这个过程可能需要一些时间， 等待该过程完成。在此过程中，数据库不允许写入操作。

（5）在 gprecoverseg完成后，系统进入重新同步模式并开始复制已更改的文件。当系统处于联机状态并接受数据库请求时，此进程在后台运行。

（6）重新同步过程完成后，系统状态为“已同步”（ Synchronized）。运行gpstate 命令用于验证重新同步过程状态

2.2将所有的segment恢复到原来的角色设置

当primary segment发生故障时，mirror segment会被**为primary segment。运行gprecoverseg命令之后，当前活动的segment是primary segment，失败的primary segment成为了mirror segment。segment实例不会返回到在系统初始化时配置的首选角色。这意味着某些segment主机上可能运行多个primary segment实例，而某些segment主机上运行较少的segment，即系统可能处于潜在的不平衡状态。要检查不平衡的segment并重新平衡系统，可以使用如下命令：

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

(1)运行下面命令，查看mirror segment的角色和同步状态

(2)如果有mirror segment处于非同步状态，等待他们同步完成

(3)运行gprecoverseg命令，使用-r参数将segment恢复到原来初始化时的角色设置

(4)运行gpstate -e命令，确认所有的segment是否恢复到初始化时的角色设置

2.3从双重故障中恢复

在双重故障情况下，即primary segment和mirror segment都处于失败状态。如果不同segment的主机同时发生硬件故障，则会导致primary segment和mirror segment都处于失败状态，如果发生双重故障，Greenplum数据库将不可用。要从双重故障中恢复，执行如下步骤：

(1)重启greenplum数据库

(2)再重启系统之后，运行gprecoverseg命令

(3)在gprecoverseg执行结束后，运行gpstate命令查看mirror状态信息

(4)如果segment仍是“Change Tracking”状态，则运行下面命令：

2.4从segment主机故障中恢复

如果主机处于不可操作状态（例如，由于硬件故障），可以将segment恢复到备用主机上。如果启用了mirror segment，则可以使用gprecoverseg命令将mirror segment恢复到备用主机。例如：

生成的recover_config_file文件的格式为：

   例如，要在没有配置其他文件空间的情况下恢复到与故障主机不同的另一台主机（除了默认的pg_system文件空间）：

该gp_segment_configuration和pg_filespace_entry系统目录表可以帮助确定当前的段配置，这样可以计划mirror的恢复配置。例如，运行以下查询：

热门相关：超武穿梭   最强反套路系统   横行霸道   重生之至尊千金   无限杀路