Greenplum数据库中segment故障检测-Toy模板网

这篇具有很好参考价值的文章主要介绍了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

$ gpstate -e

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

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

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

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

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

$ gpstate -m

1.2.2检查日志文件

日志文件可以提供信息以帮助确定错误的原因。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

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主机

$ ping failed_seg_host_address

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

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

$ gprecoverseg

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

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

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

$ gpstate -m

2.2将所有的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

2.3从双重故障中恢复

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

(1)重启greenplum数据库

$ gpstop -r

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

$ gprecoverseg

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

$gpstate -m

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

$ gprecoverseg -F