簡單對比Oracle和MySQL的高可用方案

下面講講關于簡單對比Oracle和MySQL的高可用方案，文字的奧妙在于貼近主題相關。所以，閑話就不談了，我們直接看下文吧，相信看完簡單對比Oracle和MySQL的高可用方案這篇文章你一定會有所受益。                                                          

Oracle的解決方案在阿里快速發展時期支撐起了核心業務的需求。大概是這樣的架構體系，看起來很龐大。里面的RAC算是一個貴族，用昂貴的商業存儲，網絡帶寬要求極高，前端大量的小機業務還有不菲的licence費用。非常典型的IOE的經典架構。

如果要考慮異地容災，那么資源配置要double,預算翻番。

MySQL的架構方案相對來說更加平民化，普通的pc就可以，但是數量級要高，做業務拆分，水平拆分就能夠橫向擴展出非常多的節點，很多大互聯網公司的MySQL集群規模都是幾百幾百的規模，上千都不稀奇。如此之多的服務資源，發生故障的概率還是有的，保證業務服務的可持續性訪問，是技術方案的關鍵。如果按照MHA的架構，基本上就是MHA Manager節點來負責整個集群的狀態，好比一個居委會大媽，對住戶的大大小小的事情都了如指掌包打聽。

當然上面的說法過于籠統，我們從一些細節入手。比如先來說說網絡的事情。

Oracle對于網絡的要求還是很嚴格的，一般都是要2塊物理網卡，每臺云服務器需要至少3個IP, Public IP,private IP,VIP，除了共享存儲，至少需要2個計算節點。

private IP是節點間互信的，Public IP和VIP在一個網段，簡單來說，VIP是對外的，是public IP所在網絡的漂移IP，在10g里面都是通過VIP來做負載均衡的，11g開始有了scan-IP,原來的VIP還是保留，所以Oracle里面的網絡配置要求還是很高的。拋開共享存儲，搭建的核心就是網絡配置了，網絡通則通。

scan-IP還可以繼續擴展，最多支持3個scan-ip,如下圖所示

當然網絡層面不只是這些，這方面的亮點Oracle就很專業了。我們有必要了解下TAF,在我的書中《Oracle DBA工作筆記》中，我這樣寫道：

TAF(Transparent Application Failover)是Oracle中對應用透明的故障轉移，在RAC環境中使用尤其廣泛。在RAC中Load Balance這塊確實做了很大的改進，從10g版本開始的多個VIP地址的Load Balance，到11g版本中的SCAN，做了很大的簡化。

而在Failover的實現中，還是有一定的使用限定，比如11g中默認的SCAN-IP的實現其實默認沒有Failover的選項，如果兩個節點中的其中一個節點掛了，那么原有的連接中繼續查詢就會提示session已經斷開，需要重新連接。客戶端TAF主要會討論Failover Method和Failover Type的一些簡單內容。

(1)Failover Method

Failover Method的主要思路就是換取故障轉移時間，或者換取資源來實現。

可以這樣來理解，假設我們存在兩個節點，如果某個session連接到了節點2，然而節點2突然掛了，為了更快處理Failover這種情況，Failover Method有preconnect和basic兩種。

— preconnect這種預連接方式還是會占用較多的資源使用，在各個節點上會預先占用一部分額外的資源，在切換時會相對更加平滑，速度更快。

— basic這種方式，則在發生Failover時，再去切換對應的資源，中間會有一些卡頓，但是對于資源的消耗相對來說要小很多。

簡單來說，basic方式會在故障發生時才去判斷，而preconnect則是未雨綢繆;從實際的應用來說，basic這種方式更加通用，也是默認的故障轉移方式。

(2)Failover Type

Failover Type實現更加豐富而且靈活，非常強大。這個時候控制粒度可以針對用戶SQL的執行情況進行控制，有select和session兩種;通過一個小例子說明一下。

比如，我們有個很大的查詢在節點2上進行，結果節點2突然掛了，對于正在執行的查詢，比如說有10 000條數據，結果剛好故障發生的時候查出了8 000條，那么剩下的2 000該怎么處理。

第一種方式就是使用select;即會完成故障切換，繼續把剩下的2 000條記錄返回，當然中間會有一些上下文環境的切換，對于用戶是透明的。

第二種方式是session;即直接斷開連接，要求重新查詢。

在10g版本中借助于VIP的配置達到Load Balance+Failover的配置如下：

racdb=
(DESCRIPTION =
(ADDRESS= (PROTOCOL= TCP)(HOST=192.168.3.101)(PORT= 1521))
(ADDRESS= (PROTOCOL= TCP)(HOST=192.168.3.201)(PORT= 1521))
(LOAD_BALANCE = yes)
(FAILOVER = ON)
(CONNECT_DATA =
(SERVER= DEDICATED)
(SERVICE_NAME = racdb)
(FAILOVER_MODE =
(TYPE= SELECT)
(METHOD= BASIC)
(RETRIES = 30)
(DELAY = 5))))
如果11g的SCAN-IP也想進一步擴展Failover，同樣也需要設置failover_mode和對應的類型。
RACDB =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = rac-scan)(PORT = 1521))
(CONNECT_DATA =
(SERVER = DEDICATED)
(SERVICE_NAME = RACDB)
)
)

從這個角度來看Oracle的方案真是精細。再來看看MySQL的方案。

分布式的方案，讓MySQL看起來像一把瑞士牛刀，對于網絡層面的要求，幾乎可以說MySQL沒有什么要求，申請一主一從，那么就只需要4個IP即可(主，從，VIP，MHA_Manager(考慮一個manager節點)),一主兩從是5個。

這一點上MySQL原生并不支持所謂的負載均衡，可以通過前端的業務來分流，比如使用中間件proxy,或者持續的拆分，達到一定的粒度后，通過架構設計的方式來滿足需求。因為基于邏輯的復制，很容易擴展，一主多從都是很常見的，代價也不高，延遲不能說沒有，只是很低，能夠適應絕大部分的互聯網業務需求。

而說到觸發MHA切換的條件，從網絡層面來看，如下的紅點都是潛在的隱患，有的是網絡的中斷，有的是網絡的延遲，發生故障的時候，保數據還是保性能穩定，都可以基于自己的需求來定制。從這一點上來說，丟失數據的概率是有的。絕對不是強一致性的無損復制。

整體來看兩種方案，RAC是集中共享，除了存儲層面的共享外，網絡層面的組播其實也會提高節點間通信的成本，所以RAC對于網絡的需求很大，如果存在延遲是很危險的，發生了腦裂就很尷尬了。MySQL MHA的方案是分布式的。支持大批量的環境，節點間通信的成本相對來說要低很多。但是從數據架構的角度來說，因為是復制的數據分布方式，所以對于存儲盡管不是共享存儲，但是對于存儲的成本還是高于RAC(不是說存儲的價格，是存儲的數據量大小).

對于以上簡單對比Oracle和MySQL的高可用方案相關內容，大家還有什么不明白的地方嗎？或者想要了解更多相關，可以繼續關注我們的行業資訊板塊。