首頁 > 文章 > 資料庫 > Oracle和MySQL的高可用方案比較分析

Oracle和MySQL的高可用方案比較分析

小云云原創: 2017-12-08 11:58:031430瀏覽

關於Oracle和MySQL的高可用方案，其實一直想要總結了，就會分為幾個系列來簡單說說。透過這樣的對比，會對兩種資料庫架構設計上的細節差異有基本的認知。 Oracle有一套很成熟的解決方案。用我在OOW上的ppt來看，是MAA的方案,今年是這個方案的16週年了。本文主要介紹了Oracle和MySQL的高可用方案比較分析,非常不錯，具有參考借鑒價值，需要的朋友可以參考下。

而MySQL因為開源的特點，社群裡推出了更多的解決方案，個人的見解，InnoDB Cluster會是MySQL以後的高可用方案標配。

而目前來看，MGR固然不錯，MySQL Cluster方案也有，PXC,Galera等方案，個人還是更傾向於MHA.

所以本文會分成幾個部分來解讀，先拿RAC和MHA來做一個基本的比較。

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的高可用方案比較分析

相關文章