Oracle RAC脑裂机制

大脑裂变通常用于描述这样一种情况：集群中的两个或多个节点彼此失去连接，但随后继续独立运行（包括访问逻辑或物理资源）。

什么是大脑断裂？

大脑分裂通常用于描述这样一种情况：集群中的两个或多个节点彼此失去连接，但随后继续独立运行（包括访问逻辑或物理资源），错误地假设其他进程不再运作或使用所述资源。简单地说，"大脑分裂 "意味着有2个或更多不同的节点集或 "队列"，两个队列之间没有通信。

例如：假设在以下情况下有 3 个节点。1. 节点 1.2 可以相互通信。2. 但是 1 和 2 不能和 3 对话，反之亦然。然后有两个同类群组：{1. 2} 和 {3}。

脑裂发生的原因

脑裂事件后的最大风险是破坏系统状态的可能性。损坏的三个典型原因：1. 在发生裂脑事件之前曾经合作的进程独立地修改相同的逻辑共享状态，从而导致系统状态视图发生冲突。这通常被称为“多主机问题”。2. 在Split-Brain 事件之后接受新请求，然后在可能损坏的系统状态上执行(因此可能进一步损坏系统状态)。3. 当分布式系统的进程“重新加入”在一起时，它们可能对系统状态或资源所有权有冲突的看法。在解决冲突的过程中，信息可能会丢失或损坏。

简单来说，在脑裂的情况下，从某种意义上说，有两个(或更多)独立的集群在同一个共享存储上工作。这有可能导致数据损坏。

集群件如何解决“脑裂”的情况?

在脑裂的情况下，投票磁盘将用于确定哪些节点存活以及哪些节点将被驱逐。共同投票结果将是：

具有更多集群节点的组(队列)存活

如果每个组中可用的节点数量相同，则具有较低节点成员的组(队列)将存活。

已经进行了一些改进，以确保负载较低的节点在系统负载高引起驱逐的情况下仍然存在。

通常，当发生裂脑时，会在 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. ###################################

以上消息表明从节点 2 到节点 1 的通信不工作，因此节点 2 只能看到 1 个节点，但节点 1 工作正常，它可以看到集群中的两个节点。为避免脑裂，节点 2 自行中止。

为确保数据一致性，RAC 数据库的每个实例都需要与其他实例保持心跳。心跳由 LMON、LMD、LMS 和 LCK 等后台进程维护。这些进程中的任何一个遇到 IPC 发送超时都会导致通信重新配置和实例驱逐以避免脑裂。控制文件与集群件层中的投票磁盘类似，用于确定哪些实例存活以及哪些实例驱逐。投票结果类似于集群件投票结果。结果，将驱逐 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 发送超时的接收方。