到了新公司，公司用的是rac，我比较熟悉mysql第三方的集群方案Galera Cluster这类多主集群，

下面是我参考了他人对rac的介绍，然后和mysql方案进行的臆测级别的分析对比。

rac和mysql Galera Cluster（mgc）的对比，

1、实施和运维，rac是商业方案系统化性当然强点，mgc大多使用各种开源高可用负载均衡器，部署起来对实施人员的要求rac比较低，废话。。。rmb都给了甲骨文了，如果是自行配制弄得不好性能2台还不如一台，其实运维方面来说体量大了都一样；

2、相通性，都是多点事务方案，事务可以在事务节点集群中的任何一个开始，理论上将中间失败也可以自动去另一个节点继续，提交事务是到每台节点上同步，看有没有一个节点上因为锁出现不能提交，那样就事务回滚了，

3、不同性，rac事务节点集群跟数据节点集群分离，数据默认并不冗余，只有事务在运行状态下在事务节点冗余，当然有的时候都在一台机器上，但是至少是不同进程，而包mysql在内的其他主流sqldb的事务、数据似乎都在一起，是真正的多主，冗余量高，而rac应该算事务节点冗余，数据不冗余，如果不从底层数据节点做游离于rac架构之外的底层数据节点冗余，那么rac怎么都不可能比同样节点数量的单机甲骨文实例要性能高，

这样产生的优缺点：

1、rac的数据节点当然首先节省硬盘空间，理论上可以针对库、表、表分区级别进行选择物理不同的数据节点、硬盘进行冗余进行底层冗余，不像mgc要么都冗余，要么都不冗余

2、mysql每个节点 同时是适合写和读的，所以mgc的多主不仅提高了事务的并发能力，更同时增加了不上读锁的数据的读取并发能力，这点远超rac

3、rac本身虽然是高可用方案，故障转移方案，有很高的运维上的可用性要求，层次过多，运维要求很高，当然你可以全交给dba和甲骨文付费服务，自己弄要求非常高，这方面mysql的因为层次少些相对容易运维，当然前提是你的运维人员本来就对mysql集群方案玩的很溜，否则你如果是个产品经理或者项目经理只能觉得mysql不好搞

4、mgc同时抱有对读写、事务的性能提升，并且直接是高可用的，结构简单，单点问题比rac，因为层次少了，所以应该会少，

5、rac得益于甲骨文的天生特效，更适合统计类、bi类，这方面mysql没辙，比不了

6、mgc适合主热数据的读写，不太适合做复杂的关联查询，应该比较适宜业务偏简单的互联网应用

本质上，很多人用甲骨文的原因仅仅是不敢把宝押在开源和名声稍有问题的mysql上。企业应用用甲骨文 实在多少有点冤大头 哈哈哈

互联网就该考虑mysql，如果要兼容并联查询能力 实施pgsql吧