从Segment失效中恢复

从Segment失效中恢复

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

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

确定可以从Master主机连接到该Segment主机。例如：
```
$ ping failed_seg_host_address
```
排查解决妨碍Master主机连接到Segment主机的问题。例如，主机可能需要被重启或者替换。
在主机上线并且能连接到它后，从Master主机运行gprecoverseg工具来重新激活失效的Segment实例。例如：
```
$ gprecoverseg
```
恢复过程会启动失效的Segment并且确定需要同步的已更改文件。该过程可能会花一些时间，请等待该过程结束。在此过程中，数据库的写活动会被禁止。
在gprecoverseg完成后，系统会进入到Resynchronizing模式并且开始复制更改过的文件。这个过程在后台运行，而系统处于在线状态并且能够接受数据库请求。
当重新同步过程完成时，系统状态是Synchronized。运行gpstate工具来验证重新同步过程的状态：
```
$ gpstate -m
```

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

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

$ gpstate -e

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

运行gpstate -m来确保所有镜像都是Synchronized。
```
$ gpstate -m
```
如果有任何镜像处于Resynchronizing模式，等它们完成。
用-r选项运行gprecoverseg，让Segment回到它们的首选角色。
```
$ gprecoverseg -r
```
在重新平衡之后，运行gpstate -e来确认所有的Segment都处于它们的首选角色。
```
$ gpstate -e
```

要从双重故障中恢复

在双重故障中，主Segment和它的镜像都宕掉。如果在不同的Segment主机上同时发生硬件失效，就有可能发生这种情况。如果发生双重故障，Greenplum数据库会变得不可用。要从一次双重故障中恢复：

重启Greenplum数据库：
```
$ gpstop -r
```
在系统重启后，运行gprecoverseg：
```
$ gprecoverseg
```
在gprecoverseg完成后，使用gpstate检查镜像的状态：
```
$ gpstate -m
```
如果仍有Segment处于Change Tracking模式，运行一次完整复制恢复：
```
$ gprecoverseg -F
```

如果无法恢复一台Segment主机并且损失了一个或者多个Segment，可以从备份文件中重新创建Greenplum数据库系统。请见备份和恢复数据库。

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

确定能够从Master主机连接到该Segment主机。例如：
```
$ ping failed_seg_host_address
```
排查解决妨碍Master主机连接到Segment主机的问题。例如，主机可能需要被重新启动。
在主机在线之后，验证能够连接到它并且重启Greenplum数据库。例如：
```
$ gpstop -r
```
运行gpstate工具验证所有的Segment实例都在线：
```
$ gpstate
```

上级主题： 恢复失效的Segment