Oracle Clusterware就是oracle 集群，由多个节点组成。
成都创新互联公司服务紧随时代发展步伐，进行技术革新和技术进步，经过10多年的发展和积累，已经汇集了一批资深网站策划师、设计师、专业的网站实施团队以及高素质售后服务人员，并且完全形成了一套成熟的业务流程，能够完全依照客户要求对网站进行成都网站设计、网站建设、建设、维护、更新和改版，实现客户网站对外宣传展示的首要目的，并为客户企业品牌互联网化提供全面的解决方案。
RAC中的脑裂：每个节点都有一个私有IP，供集群内部通信和传输数据，我们叫做心跳，当心跳不通时，每个节点都会认为自己是好的，都会认为其他节点宕机了，集群就出现脑裂。解决脑裂的办法去了解下votedisk
脑裂了某些原因导致心跳线无法连接。
这时候每个NODE都是独立的个体了。
突然心跳线恢复了。然后节点们互相争主权。
然后就各种异常了。
现在新版本的11g的oracle rac给的方案都重启,重新组成集群。
针对OracleCluster，如果其中一个节点被踢出Cluster，无论是因为内部的同步问题，或是时间不一致等其他错误，只要有节点非人为的被踢出 Cluster就可以称作脑裂.
在集群中，节点间通过心跳来了解彼此的健康状态，以确保各节点协调工作。假设只有“心跳”出现问题，但各个节点还在正常运行，这时，每个节点都认为其它的节点宕机了，自己才是整个集群环境中的“唯一健在者”，自己应该获得整个集群的“控制权”。在集群环境中，存储设备都是共享的，这就意味着数据灾难。简单点说，就是如果由于私有网络硬件或软件的故障，导致集群节点间的私有网络在一定时间内无法进行正常的通信，这种现像称为脑裂。在发生脑裂情况后，集群的某些节点间的网络心跳丢失，但磁盘心跳依然正常，集群根据投票算法（Quorum Algorithm）将不正确的节点踢出集群。磁盘心跳的主要目的是当集群发生脑裂时可以帮助指定脑裂的解决方案。
私网网络不能正常通信有一个超时时间，称为MC（Misscount），默认为30s（通过命令“crsctl get css misscount”查询）。该时间允计集群节点间不能正常通信的最大时间为30s，如果超过30s，那么Oracle认为节点间发生了脑裂。在出现脑裂后，集群的重要任务就是保证错误节点与正确节点间的I/O是隔离的，这样才能避免对数据造成不一致的损坏。处理这个问题的方法就是：踢出错误节点执行修复过程。
OracleRACCSS提供2种后台服务包括群组管理(GroupManagment简称GM)和节点监控(NodeMonitor简称NM)，其中GM管理组(group)和锁(lock)服务。在集群中任意时刻总有一个节点会充当GM主控节点(masternode)。集群中的其他节点串行地将GM请求发送到主控节点(masternode)，而masternode将集群成员变更信息广播给集群中的其他节点。组成员关系(groupmembership)在每次发生集群重置(clusterreconfiguration)时发生同步。每一个节点独立地诠释集群成员变化信息。而节点监控NM服务则负责通过skgxn(skgxn-libskgxn.a，提供节点监控的库)与其他厂商的集群软件保持节点信息的一致性。此外NM还提供对我们熟知的网络心跳(Networkheartbeat)和磁盘心跳(Diskheartbeat)的维护以保证节点始终存活着。当集群成员没有正常Networkheartbeat或Diskheartbeat时NM负责将成员踢出集群，被踢出集群的节点将发生节点重启(reboot)。NM服务通过OCR中的记录(OCR中记录了Interconnect的信息)来了解其所需要监听和交互的端点，将心跳信息通过网络发送到其他集群成员。同时它也监控来自所有其他集群成员的网络心跳Networkheartbeat，每一秒钟都会发生这样的网络心跳，若某个节点的网络心跳在misscount(bytheway:10.2.0.1中Linux上默认misscount为60s，其他平台为30s，若使用了第三方vendorclusterware则为600s，但10.2.0.1中未引入disktimeout；10.2.0.4以后misscount为60s,disktimeout为200s；11.2以后misscount为30s:CRS-4678:Successfulgetmisscount30forClusterSynchronizationServices,CRS-4678:Successfulgetdisktimeout200forClusterSynchronizationServices)指定的秒数中都没有被收到的话，该节点被认为已经”死亡”了。NM还负责当其他节点加入或离开集群时初始化集群的重置(Initiatesclusterreconfiguration)。在解决脑裂的场景中，NM还会监控votingdisk以了解其他的竞争子集群(subclusters)。关于子集群我们有必要介绍一下，试想我们的环境中存在大量的节点，以Oracle官方构建过的128个节点的环境为我们的想象空间，当网络故障发生时存在多种的可能性，一种可能性是全局的网络失败，即128个节点中每个节点都不能互相发生网络心跳，此时会产生多达128个的信息”孤岛”子集群。另一种可能性是局部的网络失败，128个节点中被分成多个部分，每个部分中包含多于一个的节点，这些部分就可以被称作子集群(subclusters)。当出现网络故障时子集群内部的多个节点仍能互相通信传输投票信息(votemesg),但子集群或者孤岛节点之间已经无法通过常规的Interconnect网络交流了，这个时候NMReconfiguration就需要用到votingdisk投票磁盘。因为NM要使用votingdisk来解决因为网络故障造成的通信障碍，所以需要保证votingdisk在任意时刻都可以被正常访问。在正常状态下，每个节点都会进行磁盘心跳活动，具体来说就是会到投票磁盘的某个块上写入disk心跳信息，这种活动每一秒钟都会发生，同时CSS还会每秒读取一种称作”killblock”的”赐死块”，当”killblock”的内容表示本节点被驱逐出集群时，CSS会主动重启节点。为了保证以上的磁盘心跳和读取”killblock”的活动始终正常运作CSS要求保证至少(N/2+1)个投票磁盘要被节点正常访问，这样就保证了每2个节点间总是至少有一个投票磁盘是它们都可以正常访问的，在正常情况下(注意是风平浪静的正常情况)只要节点所能访问的在线votingdisk多于无法访问的votingdisk，该节点都能幸福地活下去，当无法访问的votingdisk多于正常的votingdisk时，ClusterCommunicationService进程将失败并引起节点重启。所以有一种说法认为votingdisk只要有2个足以保证冗余度就可以了，没有必要有3个或以上votingdisk，这种说法是错误的。Oracle推荐集群中至少要有3个votingdisks。补充1：Question:有同学问那么votingdisk必须是奇数个呢？Answer:实际上我们仅仅是推荐使用奇数个votedisk，而非必须是奇数个。10gR2中votedisk的数目上限是32个。Question我们可以使用2或4个votedisk吗？Answer:可以的。但是2、4这样的数目在“至少(N/2+1)个投票磁盘要被节点正常访问”这一diskheartbeat的硬性算法下是不利的：当我们使用2个votedisk时，不能发生任意个votedisk的心跳失败当我们使用3个votedisk时，不能发生大于1个的votedisk心跳失败当我们使用4个votedisk时，不能发生大于1个的votedisk心跳失败，这和3个时的容错率是一样，但是因为我们有的votedisk，这会导致管理成本和引入的风险增长当我们使用5个votedisk时，不能发生大于2个的votedisk心跳失败当我们使用6个votedisk时，仍然不能发生大于2个的votedisk心跳失败，同样的因为比5时多出一个，也会引入不合理的管理成本和风险补充2：Question:若节点间的网络心跳正常，且节点所能正常心跳的votedisk大于不能正常访问的，如3个votedisk时恰巧有1个votedisk的diskheartbeat超时，此时Brainsplit会发生吗？Answer:这种情况即不会触发BrainSplit，也不会引发节点驱逐协议(evictionprotocol)。当单个或小于(N/2+1)个的votingdisk心跳失败(diskheartbeatfailure)时，这种心跳失败可能是由于短期内节点访问votingdisk发生I/Oerror错误而引起的，此时css会立刻将这些失败的votingdisk标记为OFFLINE。虽然有一定数量的votingdiskOFFLINE了，但是我们仍有至少(N/2+1)个投票磁盘可用，这保证了evictionprotocol不会被调用，所以没有节点会被reboot重启。紧接着nodemonitor模块的DiskpingMonitorThread(DPMT-clssnmDiskPMT)会重复尝试访问这些失败的OFFLINEvotingdisk，若这些投票磁盘变得再次可I/O访问且经过验证其上的数据也没有讹误，那么css会再次将此votingdisk标记为ONLINE；但是如果在45s(这里的45s是基于misscount和内部算法获得的)内仍不能正常访问相关的votingdisk，那么DMPT将在cssd.log中生成警告信息，如：
这2天在面试DBA Candidate的时候，我问到Oracle RAC中Brain Split脑裂决议的一些概念， 几乎所有的Candidate都告诉我当”只有2个节点的时候，投票算法就失效了，会让2个节点去抢占Quorum Disk，最先获得的节点将活下来” 。 我们姑且把这套理论叫做” 抢占论”。
“抢占论”的具体观点可能与下面这一段文字大同小异:
“在集群中，节点间通过某种机制(心跳)了解彼此的健康状态，以确保各节点协调工作。 假设只有”心跳”出现问题， 各个节点还在正常运行， 这时，每个节点都认为其他的节点宕机了， 自己是整个集群环境中的”唯一建在者”，自己应该获得整个集群的”控制权”。 在集群环境中，存储设备都是共享的， 这就意味着数据灾难， 这种情况就是”脑裂”
解决这个问题的通常办法是使用投票算法(Quorum Algorithm). 它的算法机理如下：
观点1：
集群中各个节点需要心跳机制来通报彼此的”健康状态”，假设每收到一个节点的”通报”代表一票。对于三个节点的集群，正常运行时，每个节点都会有3票。 当结点A心跳出现故障但节点A还在运行，这时整个集群就会分裂成2个小的partition。 节点A是一个，剩下的2个是一个。 这是必须剔除一个partition才能保障集群的健康运行。 对于有3个节点的集群， A 心跳出现问题后， B 和 C 是一个partion，有2票， A只有1票。 按照投票算法， B 和C 组成的集群获得控制权， A 被剔除。
观点2：
如果只有2个节点，投票算法就失效了。 因为每个节点上都只有1票。 这时就需要引入第三个设备：Quorum Device. Quorum Device 通常采用饿是共享磁盘，这个磁盘也叫作Quorum disk。 这个Quorum Disk 也代表一票。 当2个结点的心跳出现问题时， 2个节点同时去争取Quorum Disk 这一票， 最早到达的请求被最先满足。 故最先获得Quorum Disk的节点就获得2票。另一个节点就会被剔除。“
以上这段文字描述中观点1 与我在Oracle RAC Brain Split Resolution 一文中提出的看法其实是类似的。 这里再列出我的描述:
在脑裂检查阶段Reconfig Manager会找出那些没有Network Heartbeat而有Disk Heartbeat的节点，并通过Network Heartbeat(如果可能的话)和Disk Heartbeat的信息来计算所有竞争子集群(subcluster)内的节点数目，并依据以下2种因素决定哪个子集群应当存活下去:
拥有最多节点数目的子集群(Sub-cluster with largest number of Nodes)
若子集群内数目相等则为拥有最低节点号的子集群(Sub-cluster with lowest node number)，举例来说在一个2节点的RAC环境中总是1号节点会获胜。
补充：关于 我引入的子集群的概念的介绍：
“在解决脑裂的场景中，NM还会监控voting disk以了解其他的竞争子集群(subclusters)。关于子集群我们有必要介绍一下，试想我们的环境中存在大量的节点，以Oracle官方构建过的128个节点的环境为我们的想象空间，当网络故障发生时存在多种的可能性，一种可能性是全局的网络失败，即128个节点中每个节点都不能互相发生网络心跳，此时会产生多达128个的信息”孤岛”子集群。另一种可能性是局部的网络失败，128个节点中被分成多个部分，每个部分中包含多于一个的节点，这些部分就可以被称作子集群(subclusters)。当出现网络故障时子集群内部的多个节点仍能互相通信传输投票信息(vote mesg),但子集群或者孤岛节点之间已经无法通过常规的Interconnect网络交流了，这个时候NM Reconfiguration就需要用到voting disk投票磁盘。”
from askmaclean
