大腦裂變通常用于描述這樣一種情況：集群中的兩個或多個節(jié)點彼此失去連接，但隨后繼續(xù)獨立運行（包括訪問邏輯或物理資源）。

大腦分裂通常用于描述這樣一種情況：集群中的兩個或多個節(jié)點彼此失去連接，但隨后繼續(xù)獨立運行（包括訪問邏輯或物理資源），錯誤地假設(shè)其他進程不再運作或使用所述資源。簡單地說，"大腦分裂 "意味著有2個或更多不同的節(jié)點集或 "隊列"，兩個隊列之間沒有通信。

例如：假設(shè)在以下情況下有 3 個節(jié)點。1. 節(jié)點 1.2 可以相互通信。2. 但是 1 和 2 不能和 3 對話，反之亦然。然后有兩個同類群組：{1. 2} 和 {3}。

腦裂事件后的最大風(fēng)險是破壞系統(tǒng)狀態(tài)的可能性。損壞的三個典型原因：1. 在發(fā)生裂腦事件之前曾經(jīng)合作的進程獨立地修改相同的邏輯共享狀態(tài)，從而導(dǎo)致系統(tǒng)狀態(tài)視圖發(fā)生沖突。這通常被稱為“多主機問題”。2. 在Split-Brain 事件之后接受新請求，然后在可能損壞的系統(tǒng)狀態(tài)上執(zhí)行(因此可能進一步損壞系統(tǒng)狀態(tài))。3. 當(dāng)分布式系統(tǒng)的進程“重新加入”在一起時，它們可能對系統(tǒng)狀態(tài)或資源所有權(quán)有沖突的看法。在解決沖突的過程中，信息可能會丟失或損壞。

簡單來說，在腦裂的情況下，從某種意義上說，有兩個(或更多)獨立的集群在同一個共享存儲上工作。這有可能導(dǎo)致數(shù)據(jù)損壞。

在腦裂的情況下，投票磁盤將用于確定哪些節(jié)點存活以及哪些節(jié)點將被驅(qū)逐。共同投票結(jié)果將是：

具有更多集群節(jié)點的組(隊列)存活

如果每個組中可用的節(jié)點數(shù)量相同，則具有較低節(jié)點成員的組(隊列)將存活。

已經(jīng)進行了一些改進，以確保負載較低的節(jié)點在系統(tǒng)負載高引起驅(qū)逐的情況下仍然存在。

通常，當(dāng)發(fā)生裂腦時，會在 ocssd.log 中看到類似以下的消息：

1. [ CSSD]2011-01-12 23:23:08.090 [1262557536] >TRACE: clssnmCheckDskInfo: Checking disk info...

2. [ CSSD]2015-01-12 23:23:08.090 [1262557536] >ERROR: clssnmCheckDskInfo: Aborting local node to avoid splitbrain.

3. [ CSSD]2015-01-12 23:23:08.090 [1262557536] >ERROR: : my node(2), Leader(2), Size(1) VS Node(1), Leader(1), Size(2)

4. [ CSSD]2015-01-12 23:23:08.090 [1262557536] >ERROR:

5. ###################################

6. [ CSSD]2015-01-12 23:23:08.090 [1262557536] >ERROR: clssscExit: CSSD aborting

7. ###################################

以上消息表明從節(jié)點 2 到節(jié)點 1 的通信不工作，因此節(jié)點 2 只能看到 1 個節(jié)點，但節(jié)點 1 工作正常，它可以看到集群中的兩個節(jié)點。為避免腦裂，節(jié)點 2 自行中止。

為確保數(shù)據(jù)一致性，RAC 數(shù)據(jù)庫的每個實例都需要與其他實例保持心跳。心跳由 LMON、LMD、LMS 和 LCK 等后臺進程維護。這些進程中的任何一個遇到 IPC 發(fā)送超時都會導(dǎo)致通信重新配置和實例驅(qū)逐以避免腦裂。控制文件與集群件層中的投票磁盤類似，用于確定哪些實例存活以及哪些實例驅(qū)逐。投票結(jié)果類似于集群件投票結(jié)果。結(jié)果，將驅(qū)逐 1 個或多個實例。

實例警報日志中的常見消息類似于：

1. alert log of instance 1:

2. ---------

3. Mon Dec 07 19:43:05 2011

4. IPC Send timeout detected.Sender: ospid 26318

5. Receiver: inst 2 binc 554466600 ospid 29940

6. IPC Send timeout to 2.0 inc 8 for msg type 65521 from opid 20

7. Mon Dec 07 19:43:07 2011

8. Communications reconfiguration: instance_number 2

9. Mon Dec 07 19:43:07 2011

10. Trace dumping is performing id=[cdmp_20091207194307]

11. Waiting for clusterware split-brain resolution

12. Mon Dec 07 19:53:07 2011

13. Evicting instance 2 from cluster

14. Waiting for instances to leave:

15. 2

16. ...

1. alert log of instance 2:

2. ---------

3. Mon Dec 07 19:42:18 2011

4. IPC Send timeout detected. Receiver ospid 29940

5. Mon Dec 07 19:42:18 2011

6. Errors in file

7. /u01/app/oracle/diag/rdbms/bd/BD2/trace/BD2_lmd0_29940.trc:

8. Trace dumping is performing id=[cdmp_20091207194307]

9. Mon Dec 07 19:42:20 2011

10. Waiting for clusterware split-brain resolution

11. Mon Dec 07 19:44:45 2011

12. ERROR: LMS0 (ospid: 29942) detects an idle connection to instance 1

13. Mon Dec 07 19:44:51 2011

14. ERROR: LMD0 (ospid: 29940) detects an idle connection to instance 1

15. Mon Dec 07 19:45:38 2011

16. ERROR: LMS1 (ospid: 29954) detects an idle connection to instance 1

17. Mon Dec 07 19:52:27 2011

18. Errors in file

19. /u01/app/oracle/diag/rdbms/bd/BD2/trace/PVBD2_lmon_29938.trc

20. (incident=90153):

21. ORA-29740: evicted by member 0. group incarnation 10

22. Incident details in:

23. /u01/app/oracle/diag/rdbms/bd/BD2/incident/incdir_90153/BD2_lmon_29938_i90153.trc

在上面的示例中，實例 2 LMD0 (pid 29940) 是 IPC 發(fā)送超時的接收方。