众所周知，当集群出现问题时，例如某个节点丢失网络心跳，或者不能够访问表决盘，或者节点出现了严重的性能问题等，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/sdb82010-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: 4Additional information: 720913Additional 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 ?该节点被驱逐出集群，也就是重启GI2013-01-14 23:49:52.235: [ CSSD][31]###################################2013-01-14 23:49:52.235: [ CSSD][31]clssscExit: CSSD aborting from thread clssnmvKillBlockThread2013-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已经不能正常工作，节点重启仍然不可避免。具体关于如何诊断节点重启的问题，请参考之前的文章 “”。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进行诊断。