以下内容来自社区探讨，欢迎点击阅读原文到社区与同行交流本话题��������,��չ�䳤
基于Oracle RAC 双活方案实施，如何规避脑裂这个风险？
基于ORACLE RAC 双活方案实施，难点在于远距离光纤条件下的节点之间的数据交互，尤其因为仲裁的原因，导致出现的脑裂现象较多，我们应该如何规避这个风险？（问题来自@skey_deng 某农商行 系统运维工程师）
@asdf-asdf 研究学者：
磁盘心跳，ip心跳，共享NAS心跳盘做备份。
当然，网络连接速度和SAN链接速度必须保证。
@wanggeng 某银行 系统运维工程师：
数据库的仲裁是通过参数missmount设置，要想不发生脑裂的现象，如何设置这个参数参数很重要，其中需要参考光纤速率，光纤稳定性，业务响应时间等诸多因素进行设定。
再次，数据库集群中可以设置优先写，优先读等关键参数，比如主中心注重写，备中心偏重读，这里面可以设置scanip的分配策略等。
@Switcher 某银行 数据库管理员：
RAC尽量选择在同机房部署，同城机房或者异地机房尽量以ADG为主。
当然，对于某些企业有自己专用线路并且线路还是多条冗余，不依赖供应商线路的企业，做跨机房的RAC才会推荐。
@jampg 某大型保险 系统运维工程师：
我们的RAC的确还没有异地机房部署的案例，根据经验也不是很建议。
@03500408 gansubank 数据库管理员：
脑裂分两个层面，一个层面是共享存储的脑裂，另外一个层面是数据库RAC层面的脑裂，共享存储的脑裂通过第三方站点仲裁避免，数据库层面的脑裂通过磁盘心跳和网络心跳避免，由于发生心跳网络中断时可能同时导致存储和数据库的仲裁，所以就要优先进行存储的仲裁，存储仲裁完将会导致数据库的磁盘心跳的仲裁，这样就避免了存储和数据库的仲裁不一致的情况。当然存储仲裁的第三方站点是放在另外的机房的一般不会同时第三方站点损坏，存储心跳和数据库心跳也中断的情况。
@Dennis_Cai 系统工程师：
对于RAC脑裂，建议心跳与磁盘仲裁都冗余。如果是多套存储或者异地，楼上采用第三方仲裁楼上兄弟也说了。这里我有个建议，就是加入为2个节点，尽量保证一个节点能支撑业务，个人曾经试过由于交换机问题，RAC出现脑裂，二节点直接被重启了，导致业务受影响，这使我甚至没有时间去仔细去排查故障就得立刻恢复节点。
@韩成亮 某金融 数据库架构师：
脑裂的情况是一般是实例层或者集群层。
内网网络连接中断 2个实例都是正常的这个时候数据会不一致，这个时候就脑裂了， 集群层会把其中一个节点踢出去强制重启，修复数据，这个也是网络波动的时候一直有重启的原因。
当然脑裂发生的时候，总会有一个节点由于表决盘的心跳机制会存活，脑裂是为了解决数据的不一致。
麻烦说下具体的双活架构图。Oracle RAC的双活 主要看你基于哪一种做的：
RAC
Extended RAC
Extended RAC +EMC VPLEX 等
@梅志荣 某金融公司 系统架构师：
Oracle RAC在同城双活实践中业务数据同步非常重要，网络延时以及数据同步模式的选择直接影响到业务端响应速度的感受。用于业务数据同步的物理网络存在网络延迟或者网络抖动的情况，Oracle RAC环境下为了保证RAC节点间数据的可用性和一致性，引入仲裁盘（卷）的机制，能够有效避免由于业务数据网络问题引起的所谓“脑裂”的情况出现。
Oracle引入的仲裁盘机制有两个比较常用的模式，一个是利用共享存储（并发卷组）中的仲裁逻辑卷（LVs）（一般可以配置为奇数，3个或者5个），发生“脑裂”时，通过判断RAC节点获得仲裁卷的数量多少判决被宕机的RAC节点；另一种模式是在第三方机房内部署仲裁站点（服务器），双活站点与仲裁站点网络可达，通过iscsi或者NFS分配给不同RAC节点仲裁盘，判决原理同仲裁逻辑卷，只是仲裁卷变成仲裁盘（PVs）。
两种模式可以依据用户环境的实践情况做出选择，如果不考虑经济因素，建议采用第二种模式，理由是第三方站点受到同城业务网络影响不大，不会出现误判，而且第三方站点网络质量一般不会影响双活业务环境。
个人理解，仅供参考！