同城双活数据中心如果使用Oracle extent RAC，如何有效避免数据库脑裂？

Oracle官方的手册对于脑裂的问题解决方案示例如下：

Oracle尚未测试距离对第三个基于位置的投票文件的影响，因为通常假设第三个位置理想地与数据中心的距离相近，因为两个数据中心彼此相邻。 但是，只要确保第三个投票文件的可访问性并且考虑到从数据中心到第三个位置的距离增加不仅会导致延迟、而且会增加路径上的故障风险，客户也可以为第三个位置选择任何距离。
关于投票盘的读写，官方文档如下：
Minimum network requirements for the connectivity to the third location can therefore be derived from the access patterns to Voting Files in an Oracle cluster. In general, Oracle Clusterware accesses a Voting File every second for read and write with less than a kilobyte of data read or written. An acknowledgement of the write I/O needs to be received in 200 seconds under normal operations (long disk timeout) and 27 seconds during a reconfiguration in the cluster (short disk timeout).
In order to meet those response time requirements (latencies) for accessing the third Voting File hosted on standard NFS or using iSCSI based connectivity, Oracle recommends setting up the system to meet half of the lower latency requirement in average. In other words, the connectivity to the third location should ensure that the Voting File write I/O can be acknowledged in 27/2 seconds (approx. 14 seconds), providing a minimum average throughput of at least 128 Kbps。
根据上文，通常Oracle Clusterware每秒访问一个表决文件进行读写，读取或写入的数据少于一千字节。 在正常操作（长磁盘超时）下需要在200秒内接收写入I / O的确认，在群集中重新配置期间需要接收27秒（短磁盘超时）。为了满足访问标准NFS上托管的第三个投票文件或使用基于iSCSI的连接的响应时间要求（延迟），Oracle建议将系统设置为平均满足较低延迟要求的一半。 换句话说，与第三个位置的连接应该确保可以在27/2秒（大约14秒）内确认投票文件写入I / O，提供至少128 Kbps的最小平均吞吐量

可以采用在RAC集群上建立vote磁盘的方式，将第三块vote盘部署在仲裁中心，以保障脑裂情况下首先拿到votedisk的rac节点正常运行，另一个节点主动重启。