關於Oracle的rac叢集和mysql Galera Cluster的想法

標籤：

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

關於Oracle的rac叢集和mysql Galera Cluster的想法