Oracle和MySQL的高可用方案對比（一）

關於Oracle和MySQL的高可用方案，其實一直想要總結了，就會分為幾個系列來簡單說說。透過這樣的對比，會對兩種資料庫架構設計上的細節差異有一個基本的認識。Oracle有一套很成熟的解決方案。用我在OOW上的ppt來看，是MAA的方案,今年是這個方案的16週年了。

而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=

(DEION =

(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 =

(DEION =

(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(不是說儲存的價格，是儲存的資料量大小).