此版本的修补软件和已作的修复

问题和解决方案

问题：如果所有的共享卷组都已从属于现有的群集，则执行 cmquerycl 命令将无法将群集锁卷组和物理卷组装入新的模板文件。例如，如果有一个单节点群集，然后执行 cmquerycl 命令来组成一个双节点群集，则在模板文件中不能装入群集锁的信息。模板文件中的警告消息不会清楚地说明是因为这个卷组已属于现有的群集：

# Warning:No volume groups were found on all nodes.
# A cluster lock volume group is required for clusters of only two nodes.

解决方案： 在群集 ASCII 文件中添加注释，表明不能找到群集锁的任何共享卷组是因为所有的卷组都从属于一个现有的群集。

问题：由于出现了 sendto() 函数失败而导致不能启动 cmservassistd 守候进程，从而引发 ServiceGuard 发生控制转移 (TOC)。

解决方案： 现在已为网络调用增加了重试机制，可以处理瞬时的错误。

问题： cmcld 异常中止时，由于接收到无效的参数而导致 cl_kepd_printf 失败。

解决方案：已对代码进行了修改，添加了记录处理，这样以后再遇到这种问题时分析过程将变得更简单。cmcld 异常中止时，只要 cl_kepd_printf 无法打印到 TOC 转储，则将调用 fstat() 函数还获取文件状态并将状态信息记录到系统日志中。

问题： 网络传感器 (network sensor) 在 0 级记录时不能报告某些 ioctl() 错误。如果有任何驱动程序发生故障会导致 ioctl() 失败，它们不能被记录到系统日志 (syslog) 中。

解决方案： 修改代码以使在 0 级时可记录 ioctl() 失败。这样可帮助判别系统日志文件中是否出现驱动程序的错误消息。

问题： 在 SG-OPS 群集上运行 cmgmsd，在处理高级别事务时 cmcld 会占用大量的 CPU 资源。在单 CPU 系统中会造成 cmcld （实时进程） 占用系统阻止其他进程运行。

解决方案： 已做了修改。 1) 消除了不必要的 begin_trans 语句，从而几乎不会发生 begin_trans 失败的情况。 2) 如果发生 begin_trans 失败则降低重试的次数。

问题： 每小时进行的群集锁运行情况检查未检测到有故障的设备 — 返回 EBUSY 消息，并且 ServiceGuard 不能可靠地报告出现故障的群集锁设备。

解决方案： 一般说来，我们认为带有 EBUSY 返回消息的 LVM 问题是 SCSI 驱动程序中的问题。使用 SCSI 修补软件 PHKL_19776 或更高版本可以修复这个问题。已进行代码修改，当在检查时返回 EBUSY，则 ServiceGuard 将获得一个警告消息，这种情况下 cmcld 不能获得 LVM 的状态。（如果没有应用 PHKL_19776 修补软件则会发生这种情况）。

问题： ServiceGuard 群集上的所有节点同时记录下面的消息：

cmclconfd:Unable to bind to network interface:Device busy 
cmclconfd:Unable to establish a subsequent link level binding on network interface # (NMID):Device busy 

nettl.LOG00 中未记录任何节点有网络错误。

解决方案： 重新设计了代码，进行网络探查来消除上述问题。

问题： ServiceGuard OPS Edition 经过了失败的 cmgmsd 事务处理，这可能导致不能暂停节点。这个问题通常是由于 Oracle 关闭失败造成 ORA-600 错误而引发的。当提交事务，cmgmsd 客户机调用尝试对群集中的所有节点写入临时配置文件的例行程序时，将发生这种问题。

解决方案： 对代码做了修改，将临时文件只复制到本地节点，因而避免了在网络上传输过量的消息。

问题： cmcheckconf 和 cmapplyconf 命令程序包 ascii 文件中有无效的 RESOURCE_UP_VALUE 配置。而在它应当失败时却得到下面的成功场景：

RESOURCE_NAME /vg/vgshared_11.0/pv_summary 
RESOURCE_POLLING_INTERVAL  300
RESOURCE_START             AUTOMATIC
RESOURCE_UP_VALUE         = UP = PVG_UP

解决方案： 已对代码进行了修改，在 cmapplyconf 和 cmcheckconf 命令执行过程中当检测到有错误的 RESOURCE 配置时对错误进行报告。

问题： cmcld 命令从 recvfrom() 系统调用接收到 ENOSR 错误时异常中止。

解决方案： 已实施通用的解决方案来处理套接字调用时发生的所有瞬时错误（如 ENOSR、ENOBUFS、EINTR）。在所有套接字调用的 wrappers 中写入处理这种情况的代码。处理的方式包括在释放节点和报告内核错误之前有 10 秒种的重试和最少 10 次的重试。

如果瞬时错误超过 10 秒，ServiceGuard 会首先记录重试调用后发生内核问题，之后 ServiceGuard 异常中止。

问题： cmgmsd 对 syslog.log 进行报告：cdb 事务处理失败，不能提交并返回错误号 22（无效的参数）。

解决方案： 所做的修复是，如果从 commit_trans 接收到 errno=22 的消息就刷新连接，如果成功，cmgmsd 会尝试再次提交事务。

问题： 文件访问许可 666 对 /var/adm/SGsnmpsuba.log 文件无效。

解决方案： 处于安全的目的，已将上述文件的文件访问许可从 666 更改为 644。

问题： 有时，在 cmcld 命令异常中止后节点会进行控制转移，但有时只完成重新引导而不写入转储。

解决方案： 一般，这种情况下 cmcld 将产生一个核心文件，用 sync() 函数调用取代进行重新引导，从而将核心内容写到磁盘上。当不需要核心文件时，就退出以进行控制转移 (TOC) 而不进行重新引导。

问题： cmquerycl (1m) 联机帮助页没有说明如果群集 ASCII 文件中未列出卷，它就会被清除（未标记为群集的一部分）。

解决方案： 已修改了 cmquerycl 的联机帮助页，说明未列于 ASCII 文件的卷组将被清除。

问题： 如果未配置群集锁，在 cmcld 启动时系统日志将写入如下消息（即使群集中超过 4 个节点）：

Jan 18 11:44:43 mtl-dbd cmcld:Warning.No cluster lock is configured.

解决方案： 如果群集中超过 4 个节点，现在代码将不再记录 “No cluster lock configured”警告消息。

问题： ServiceGuard 无法使用非标准的磁盘设备文件名工作。参见如下的错误消息：

Begin cluster verification... 
 
Warning:The disk at /dev/dsk/pam on node grcdg238 does not have an ID, or a disk label. 
Error:Device  is not found on any nodes in the cluster. 
Error:Unable to determine a unique identifier for
physical volume /dev/dsk/pam on node grcdg238.
Use pvcreate(1m) to give the disk an identifier.
Error:Unable to determine a unique identifier for
physical volume /dev/dsk/pam on node grcdg236.
Use pvcreate(1m) to give the disk an identifier.
cmcheckconf  :Unable to reconcile configuration file
/etc/cmcluster/cluster.orig with discovered
configuration information.

解决方案： 问题的根本原因在于我们不能从单一的主/辅号对中获得全部设备。也就是说如果有两个设备文件（如 c1t1d0 和 disk1）指向同一个物理设备，则在扫描过程中我们只能找到其中一个。所做的修复是为每一主/辅号查看设备树中的每个条目。

问题： ATS 联机帮助页中说明，如果使用 mt(1) 在磁带设备打开前保留磁带设备，则在窗口继续打开过程中 Advanced Tape Services 工具遇到群集重新配置事件时，设备将被自动回收（释放）。（这是由于 Advanced Tape Services 工具已认定此设备为“reserved, not owned or available”）。但是测试结果显示，用 ioctl(MTRES) (mt -f /dev/rmt/st1m res) 进行的手工保留，肯定不会被 ATS 回收。

解决方案： ats(5) 联机帮助页阐明它会包括关于自动回收设备的一般规则的这个异常。

问题： OPS 8.0.x 宕机后立即重新启动，则重启失败并报告错误 ORA-29701。Oracle 跟踪文件 (ora_xxxx.trc) 报告关于 nmapi v1 lib 的下述错误消息：

Mon Mar 12 01:15:47 2001 skgxnini:ERROR:
Failed to initialize ServiceGuard
(238,Connection timed out) Mon Mar 12 01:15:47
2001 skgxnini:RETURN:SKGXN_EUNK, FALSE.

解决方案： 在 skgxnini 内部，调用 cl_init_synchonous 连接到 ServiceGuard。目前的发行版中，没有 API 可用来断开与 ServiceGuard 的连接。在客户机离开时，将清除此连接。所做的修复只是如果 cl_init_synchonous 在 skgxnini 中调用过，就不再进行第二次调用。

问题： 如果在群集重新组织过程中 /usr/lbin/cmlvmd 守候进程在一个节点上挂起，整个群集就会失败，并显示如下消息：

Timed out waiting for replies

解决方案： 增加了新的定时器，在群集重新组织过程中监视 cmlvmd 的进展。如果有任何的 cmclvmd 实例未能及时完成重新配置，它就会被强行终止，群集剩下的实例将继续执行。

问题： cmquerycl -k 仍然执行磁盘探查任务，尽管联机帮助页上说这个选项不能执行磁盘探查活动。

解决方案： 联机帮助页中加入了有关 cmquerycl -k 选项的详细叙述。现在联机帮助页中清楚地说明 -k 选项将减少磁盘探查活动，而不是完全停止磁盘探查。-k 是对磁盘探查的优化选项。

问题： cmrunnode 无法加入一个现有的群集，并显示如下错误消息：

Unable to start cluster on nodes specified. 
There appears to be a configuration operation in progress.
Attempting the operation again may succeed.

解决方案： 当检查来自代理服务器的请求消息时，新节点也会检查代理服务器是否仍为群集的一部分。