關於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工作筆記》中，我這樣寫道：
而在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(不是說儲存的**，是儲存的資料量大小).
基於Keepalived的MySQL高可用
keepalived負責的是故障轉移，至於故障轉以後的節點之間資料的一致性問題依賴於具體的複製模式。不管是主從 一主多從還是雙主 集群節點個數 主從具體的模式無關 常規複製，半同步複製，gtid複製，多執行緒複製，甚至可以是mgr 都沒有直接的關係。個人認為，mysql高可用方向，mgr 自動故障轉...
Spring Cloud 配置中心 認證和高可用
spring cloud 知識點 服務發現與服務註冊 定製rabbon客戶端負載均衡策略 spring cloud feign使用1 springcloud feign使用二 springcloud hystrix 實現 springcloud超時機制 斷路器模式簡介 spring cloud eu...
keepalived實現nginx的高可用
前言 優化nginx proxy 可能出現單點故障的情況，通過keepalived得方式來完成nginx proxy伺服器之間的高可用，因為keepalived的工作機制是通過心跳線來檢測伺服器之間是否出現故障，但是並不能檢測nginx proxy 服務是否正常工作，所以需要採用編寫指令碼判斷的方式...