RAC的脑裂问题--EVICTION
当由于网络问题，RAC的节点间无法进行通信时，出现脑裂问题，RAC必须通过驱逐其中的一部分节
点来保护数据的一致性，被驱逐的节点将被强制重启。
当节点间无法探知对方的网络心跳时，必须通过voting disk来决定驱逐那个节点。
脑裂问题可能出现在2个层面
– 集群层
– 实例层
一旦实例的内连网中断，即interconnect。两个实例之间都能正常工作，只是内连网断了。
虽然两个节点都正常工作，只是内连网断了，这样就会造成实例1处理一部分用户请求，实例2区处理另外一部分用户请求。这里表面上看起来都是没问题的，但是会造成数据一致性的问题，两个实例都在修改数据块，数据是共享的，由于网络中断了，没有cache fusion了，两个节点都不知道对方在干什么，这样就会造成数据的不一致。
当实例和实例之间网络不通了，这种情况发生称为脑裂。当节点和节点之间不通了，oracle必须做出一个决定，将其中一个实例失效，让其不对外提供功能。即两个实例之间必须有一个实例从集群里面驱逐出去。驱逐的节点将会被迫重启。
在网络不好的情况下会经常碰到节点重启，这个大多数时候都是因为脑裂的问题。当其中一个节点重启，另外一个节点就接管重启节点上面的redo和undo，提交的数据用redo来恢复，未提交的数据用undo来回滚。
总结一下脑裂就是将集群当中的一个节点踢出去，让其强制重启。
上面集群层是指CRS这一层，实例层是指instance这一层。在这两层都可能出现脑裂的问题。
RAC的脑裂问题--EVICTION
集群层脑裂问题的处理方法
– 包含更多节点的集群保留下来，包含少节点的集训将被从集群中驱逐。
– 如果形成脑裂的2个集群包含相同的节点，节点号小的集群被好留，节点号大的被驱逐。
– 当由于由于负载问题导致驱逐发生时，Oracle选择负载低的节点保留。
上面图片就是脑裂发生产生的日志，这里有checking disk info，这里的disk是表决磁盘。
之后这个节点通过表决磁盘的信息决定abort local node,将自己终止，挂起，避免发生脑裂。
原因是什么，因为本身是node(2)和node(1)比起来节点大，自己将自己牺牲掉，将自己重启。
这里有一个细节，checking disk info。A和B两个实例之间不通了，能够就因为A节点较小就将A驱逐掉吗？如果A死机了怎么办。这里就出现了表决磁盘voting disk，每一个RAC里面的实例每隔一秒钟向表决磁盘里面做一次心跳，在RAC里面有两种心跳，一种是节点和节点之间的心跳，即通过内连网之间的心跳（network heartbeat），另外一个是磁盘心跳（disk heartbeat）。
网络心跳是节点和节点之间互相探测是否发生脑裂的问题。一旦出现了脑裂之后，B节点不是立刻就驱逐了，因为A和B都互相探测不了了，谁也不知道谁真的出了故障，如果B重启了万一A死机了，那么整个实例都不能使用了。
这个时候B就要去读表决磁盘，因为每一个实例都要向表决磁盘里面发心跳信息，B在表决磁盘上收到了A的在往表决磁盘里面写信息，B得知虽然和A网络不通，但是A实例还在向表决磁盘发心跳，A实例还是正常的，所以B有充分理由将自己重启了。
当实例和实例之间不通可以通过表决磁盘感知对方是活的还是死的。如果B在表决磁盘上面收不到A的心跳信息，那么B就不会重启了。
集群层通过CSSD进程来维护节点和节点之间关系的，在集群层做心跳。
RAC的脑裂问题--EVICTION
数据库层的脑裂问题
– 为了保证数据的一致性，每个实例需要和其它实例通过网络心跳探知对方的健康情况，后台进程LMON,LMD,LMS或者LCK都会探知其它实例的运行状态，如果出现请求超时，也会进入脑裂状态，此时实例会使用控制文件来代替voting disk来决定其它实例的状态。
上面是内连网不通导致的脑裂，这里是实例和实例之间不通出现超时就必须进入脑裂状态。实例不能用voting disk，只有crs才能访问这个。这里会用一个控制文件代替voting disk，所有实例都会去访问一个共享控制文件，这个时候控制文件就发挥了表决磁盘功能去接受实例A和B的心跳，之后通过控制文件接受到的A和B的信息决定将哪个节点驱逐掉。驱逐原则还是还是和之前一样。
数据库层面的脑裂可以从数据库alter的日志里面看到
IPC send timeout detected，IPC是一个实例和实例之间通信的协议。IPC检测到发送消息超时。之后发生脑裂驱逐节点2.
脑裂问题--brain spit
当在网络层三个节点之间都是内网可以连通的同时可以向表决磁发送心跳。此时三个节点是可以互相看到对方的。
总结：脑裂问题就是为避免数据的不一致。