11gR2 新特性： Rebootless Restart

众所周知，当集群出现问题时，例如某个节点丢失网络心跳，或者不能够访问表决盘，或者节点出现了严重的性能问题等，CRS会选择将某个节点的OS 重启，以便保证集群的一致性。当然，大部分的重启都是由CRS的核心进程ocssd.bin发起的。 但是，如果CRS 只是节点上的应用之一或者私网和存储的问题只是短时间的出现，那么重启节点的行为就会导致节点上所有的应用全部停止，这在很多系统上并不是我们希望看到的。

所以从版本11.2.0.2 开始，oracle新特性rebootless restart被介绍。当出现以下情况的时候，集群件（GI）会重新启动集群管理软件，而不是将节点重启。
1.当某个节点连续丢失网络心跳超过misscount时。
2.当某个节点不能访问大多数表决盘（VF）时。
3.当member kill 被升级成为node kill的时候。
在之前的版本，以上情况，集群管理软件（CRS）会直接重启节点。

之后，我们通过几个例子了解上面提到的几种情况。
1.当某个节点连续丢失网络心跳超过misscount的情况
2010-08-13 17:00:26.213: [    CSSD][4073040800]clssnmPollingThread: node <nodename> (1) at 50% heartbeat fatal, removal in 14.540 seconds
……
2010-08-13 17:00:33.227: [    CSSD][4073040800]clssnmPollingThread: node <nodename> (1) at 75% heartbeat fatal, removal in 7.470 seconds
……
2010-08-13 17:00:38.236: [    CSSD][4073040800]clssnmPollingThread: node <nodename> (1) at 90% heartbeat fatal, removal in 2.460 seconds, seedhbimpd 1 ?本地节点report 远程节点丢失本地心跳
……
2010-08-13 17:00:40.707: [    CSSD][4052061088](:CSSNM00008: )clssnmCheckDskInfo: Aborting local node to avoid splitbrain. Cohort of 1 nodes with leader 2, <nodename>, is smaller than cohort of 1 nodes led by node 1, <nodename>, based on map type 2 ? 为了避免split-brain ，本地节点重新启动GI。
2010-08-13 17:00:40.707: [    CSSD][4052061088]###################################
2010-08-13 17:00:40.707: [    CSSD][4052061088]clssscExit: CSSD aborting from thread clssnmRcfgMgrThread 
2010-08-13 17:00:40.707: [    CSSD][4052061088]###################################
2.当某个节点不能访问大多数表决盘（VF）的情况
2010-08-13 18:31:23.782: [    CSSD][150477728]clssnmvDiskOpen: Opening /dev/sdb8
2010-08-13 18:31:23.782: [   SKGFD][150477728]Handle 0xf43fc6c8 from lib :UFS:: for disk :/dev/sdb8:

2010-08-13 18:31:23.782: [    CLSF][150477728]Opened hdl:0xf4365708 for dev:/dev/sdb8:
2010-08-13 18:31:23.787: [   SKGFD][150477728]ERROR: -9(Error 27072, OS Error (Linux Error: 5: Input/output error ? 访问表决盘出错。
Additional information: 4
Additional information: 720913
Additional information: -1)
)
2010-08-13 18:31:23.787: [    CSSD][150477728](:CSSNM00060: )clssnmvReadBlocks: read failed at offset 17 of /dev/sdb8
……
2010-08-13 18:34:38.206: [    CSSD][4110736288](:CSSNM00018: )clssnmvDiskCheck: Aborting, 0 of 1 configured voting disks available, need 1 ?在经过long disk timeout时间之后，GI被重新启动。
2010-08-13 18:34:38.206: [    CSSD][4110736288]###################################
2010-08-13 18:34:38.206: [    CSSD][4110736288]clssscExit: CSSD aborting from thread clssnmvDiskPingMonitorThread 
2010-08-13 18:34:38.206: [    CSSD][4110736288]###################################

3.member kill 被升级成为node kill的情况。
2013-01-14 23:49:52.093: [    CSSD][45]clssgmmkLocalKillThread: Time up. Timeout 30500 Start time 130388522 End time 130419022 Current time 130419087 ?member kill 超时发生
2013-01-14 23:49:52.093: [    CSSD][45]clssgmmkLocalKillResults: Replying to kill request from remote node 1 kill id 1 Success map 0x00000000 Fail map 0x00000000
……
2013-01-14 23:49:52.235: [    CSSD][31](:CSSNM00005: )clssnmvDiskKillCheck: Aborting, evicted by node <nodename>, number 1, sync 239654498, stamp 130416886 ?该节点被驱逐出集群，也就是重启GI
2013-01-14 23:49:52.235: [    CSSD][31]###################################
2013-01-14 23:49:52.235: [    CSSD][31]clssscExit: CSSD aborting from thread clssnmvKillBlockThread
2013-01-14 23:49:52.235: [    CSSD][31]###################################
2013-01-14 23:49:52.235: [    CSSD][31](:CSSSC00012: )clssscExit: A fatal error occurred and the CSS daemon is terminating abnormally

从上面的输出，我们能看到三种情况中ocssd.bin进程都能够正常地工作，当出现问题时，能过做出正确的决定。所以，rebootless restart能够保证由ocssd.bin主动发起的重启。但是，如果是由于ocssd.bin 出现问题（例如：挂起），或者操作系统性能引起的重启，rebootless restart是无法起作用的，因为，对于这种情况ocssd.bin已经不能正常工作，节点重启仍然不可避免。具体关于如何诊断节点重启的问题，请参考之前的文章 “11gR2 如何诊断节点重启问题”。

GI 在重启集群之前，首先要对集群进行graceful shutdown, 基本的步骤如下。
1．停止本地节点的所有心跳（网络心跳，磁盘心跳和本地心跳）。
2．通知cssd agent，ocssd.bin即将停止
3．停止所有注册到css的具有i/o能力的进程，例如 lmon。
4．cssd通知crsd 停止所有资源，如果crsd不能成功的停止所有的资源，节点重启仍然会发生。
5．Cssd等待所有的具有i/o能力的进程退出，如果这些进程在short i/o timeout时间内不能不能全部推迟，节点重启仍然会发生。
6．通知cssd agent 所有的有i/o能力的进程全部退出。
7．Ohasd 重新启动集群。
8．本地节点通知其他节点进行集群重配置。

综上所述，对于11.2.0.2 及以上版本的集群，如果您发现了节点重启，那么，ocssd.bin 挂���或者操作系统性能的问题应该是首先检查的内容。当然，如果rebootless restart的gracefull shutdown 不能在指定的时间内完成，节点重启仍然会发生，这需要查看ocssd.log进行诊断。