1、适用于

Oracle 19.10

2、描述

在一个3节点或更大的集群中，如果一个节点由于硬件故障、强制重新启动等而突然关闭，幸存的集群节点将通过CSS重新配置来移除突然关闭的节点。但 有时CSS重新配置无法解决问题， 这会导致集群重新配置挂起，从而导致数据库实例收回和集群中断。

3、存在的问题

 该问题如果发生，需要满足下列条件：

• 大于2个节点的群集，CSS修复，节点重新启动，并且集群中至少存在一个节点位于有问题的窗口中

相反，问题不会在下列情况下存在：

少于3个节点或CSS执行无需重新启动的恢复，或者所有幸存的节点不在有问题的窗口中，或者一个正在重新启动的节点很快返回（少于30秒

许多错误都是由CSS通过无需重启的恢复来处理的，在这种情况下，它将从潜在的挂起恢复

对于有问题的窗口，请参见下面缓解步骤中的说明

注意：此问题特定于19.10 Grid Home

4、症状

如果某个节点由于硬件故障、强制重新启动等原因突然关闭，幸存的群集节点将通过重新配置来移除突然关闭的节点。作为重构的一部分，集群通过CSS主节点选择协议来选择重构主节点。为每个重配置动态选择一个重配置主节点。所有节点都试图成为一个可重构主节点，并最终将其分解为一个节点作为主节点。由于与包装网络和磁盘心跳的时间戳（以毫秒表示）相关的问题，主选择协议无法解决。这会导致集群重新配置挂起，从而导致数据库实例收回和集群中断

5、方法

A 32-bit millisecond system clock wraps every 49 days. The problem starts to happen when a 
node is up more than 24.5 days, which is the mid-point of a 49-day window. On the 49th day,
 it wraps and starts from zero. Until it hits the mid-point of the next 49th day window, 
 the problem does not happen. Problematic window for the node, as seen by OS ‘uptime’ 
 command (number of Days): 24.5 – 49 days, 73.5 - 98 days, 122.5 – 147 days, etc. 
 Non-Problematic window for the node, as seen by OS ‘uptime’ command (number of Days):
  0 – 24.5 days, 50 – 73.5 days, 98 – 122.5 days, etc.

以下是一些减轻此问题风险的选项。

积极主动的：

监视群集中所有节点的正常运行时间。

对于问题窗口中的每个节点，

-按照标准的数据库计划维护过程关闭节点上的所有数据库实例。

-关闭CRS服务（'crsctl stop crs -f'）

-主动重新启动节点。

这将清除有问题窗口中的节点，并将其放入无问题窗口中。

问题处理类：

如果集群由于所描述的问题而处于重新配置挂起状态，那么至少有一个节点位于集群中有问题的窗口中。在有问题的窗口中可能有多个节点 。 在这种情况下，可以执行以下步骤

从重新配置挂起中清除群集。

在有问题的窗口中的一个节点上，

-关闭CRS服务（'crsctl stop crs -f'）

-如果'crsctl stop crs –f'未完成/挂起，请使用'kill-9'终止节点上的ocssd进程，

这将触发节点重新启动。

通过上述步骤，应解决重新配置挂起问题。

执行上述步骤的主动预防部分，以避免将来出现问题。

6、补丁

本例中出现的问题可以使用错误修复"30227028"解决。它通过跳过为自己重新启动的节点执行“有效性”检查来修复上述问题。

建议应用包含多个关键修复程序的合并补丁"32726497"

翻译：

Potential Complete Cluster wide outage caused by cluster reconfiguration hang (Doc ID 2767299.1)