到了新公司，公司用的是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吧