运维日记丨记录一次补丁漏打问题

在执行最后一个步骤时出现问题：

# oracle/app/11.2.0/grid/crs/install/rootcrs.pl -patch
复制

查看gird日志，报错

CRS-2302:Cannot get GPnP profile. Error CLSGPNP_NO_DAEMON (GPNPD daemon is not running)
复制

可以看到说是因为GPNP进程一直起不来，导致后续的其他组件都无法正常启动。

看到二节点正常的日志，GPNPD是正常起来了

一节点异常输出：

二节点正常

我们已经定位到是gpnpd的文件的原因，于是去找关于gpnpd的日志文件gpnpd.log

日志中看到，他一直在创建gpnpd的pid文件但是一直创建不了。

再去看另一个日志文件gpnpdOUT.log

报错：libhasgen11.so: undefined symbol: ztpk_SetKeyInfo

去万能的MOS上查看错误，有类似的报错

给出的解释有两个原因，两个原因都是类似的，都是说有补丁没有打给GI HOME报的错。

于是立马去查看一节点的GRID下的补丁

[grid@p1 gpnpd]$ oracle/grid/crs_1/OPatch/opatch lsinventory
Interim patches (2)
复制

看到只打了两个补丁，就知道完蛋了，怎么会犯这么低级的错。

MOS上给出的解决方案也是Rollback Patch

这也体现了在打补丁之前备份Oraclehome和gridhome的重要性了！

Grid Plug and Play，GPnP是Oracle 11gR2 RAC提供的新组件。该组件的功能由gpnpd.bin守护进程实现。GPnP可以提供一个动态的GI环境，能随着负载的增加而动态改变GI环境。GPnP能非常容易地添加、替换或者移除集群中的节点，就像电源插头一样即插即用。

2、通过和mdnsd进行通信，能够更灵活地识别集群中的节点，使集群结构更加灵活，不再需要从OCR中获取节点列表。

• mDNS负责在节点内部进行IP的解析，在添加节点的时候不需要手动修改每个节点的/etc/hosts文件。
• GPNPD服务提供的是集群配置信息管理，新的节点添加进来会根据现有的GPnP profile配置信息来配置新的节点，同时更新所有节点的GPnP profile文件。
  一旦新添加的节点加入到集群，SCAN机制动态地将连接分配给该节点，所有的客户端都不需要进行任何配置的变更，就能实现节点的负载均衡。

• GNS（Grid Naming Service）能动态地为新添加的节点分配VIP地址，利用DHCP管理公共网络中的IP地址。这些服务共同构成了“网格即插即用”的特性。

• gpnp wallet

  gpnp wallet 的功能是保存需要访问gpnp profile 文件的客户签名信息， 当客户访问gpnp profile 时通过wallet 中的签名信息进行验证，以确保只有指定的客户能够访问profile 文件。这部分内容是不需要用户配置的，在安装GI 时，Oracle 会自动完成签名信息的初始化。

• gpnp profile

  gpnp profile 是gpnp组件的重要部分，它是一个XML 文件，用于保存启动（ bootstrap ）集群节点时所需的必要信息。换句话说，当GI 在启动时，所有必需的信息都保存在gpnp profile中，从某种意思上说 gpnp profile中的信息类似于数据库bootstrap时所需要的信息。

该文件中包括了集群名称、网络类型（public/private）、ASM和CSS的存储信息、数字签名，以及ASM实例的SPFILE文件位置等。在集群中，CSS、GPnP等服务的启动都依赖于GPnP profile文件，该文件引导节点加入集群。如果GPnP profile文件被破坏或丢失，那么集群将无法正常启动。在集群启动期间，CSS守护进程将使用GPnP profile文件中的DiscoveryString参数发现表决磁盘文件，所以，若DiscoveryString参数配置不正确，则CSS守护进程无法启动，进而导致整个CRS无法启动。

注意：Oracle不支持手动修改profile.xml文件，直接对它的修改可能导致无法修复的问题，最终导致在所有节点重建Clusterware。