Oracle和MySQL的高可用方案對比（一）
關(guān)于Oracle和MySQL的高可用方案，其實一直想要總結(jié)了，就會分為幾個系列來簡單說說。通過這樣的對比，會對兩種數(shù)據(jù)庫架構(gòu)設(shè)計上的細節(jié)差異有一個基本的認識。Oracle有一套很成熟的解決方案。用我在OOW上的ppt來看，是MAA的方案,今年是這個方案的16周年了。
而MySQL因為開源的特點，社區(qū)里推出了更多的解決方案，個人的見解，InnoDB Cluster會是MySQL以后的高可用方案標配。
而目前來看，MGR固然不錯，MySQL Cluster方案也有，PXC,Galera等方案，個人還是更傾向于MHA.
所以本文會分為幾個部分來解讀，先拿RAC和MHA來做一個基本的對比。
Oracle的解決方案在阿里快速發(fā)展時期支撐起了核心業(yè)務的需求。大概是這樣的架構(gòu)體系，看起來很龐大。里面的RAC算是一個貴族，用昂貴的商業(yè)存儲，網(wǎng)絡帶寬要求極高，前端大量的小機業(yè)務還有不菲的licence費用。非常典型的IOE的經(jīng)典架構(gòu)。
如果要考慮異地容災，那么資源配置要double,預算翻番。
MySQL的架構(gòu)方案相對來說更加平民化，普通的pc就可以，但是數(shù)量級要高，做業(yè)務拆分，水平拆分就能夠橫向擴展出非常多的節(jié)點，很多大互聯(lián)網(wǎng)公司的MySQL集群規(guī)模都是幾百幾百的規(guī)模，上千都不稀奇。如此之多的服務資源，發(fā)生故障的概率還是有的，保證業(yè)務服務的可持續(xù)性訪問，是技術(shù)方案的關(guān)鍵。如果按照MHA的架構(gòu)，基本上就是MHA Manager節(jié)點來負責整個集群的狀態(tài)，好比一個居委會大媽，對住戶的大大小小的事情都了如指掌包打聽。
當然上面的說法過于籠統(tǒng)，我們從一些細節(jié)入手。比如先來說說網(wǎng)絡的事情。
Oracle對于網(wǎng)絡的要求還是很嚴格的，一般都是要2塊物理網(wǎng)卡，每臺服務器需要至少3個IP, Public IP,private IP,VIP，除了共享存儲，至少需要2個計算節(jié)點。
private IP是節(jié)點間互信的，Public IP和VIP在一個網(wǎng)段，簡單來說，VIP是對外的，是public IP所在網(wǎng)絡的漂移IP，在10g里面都是通過VIP來做負載均衡的，11g開始有了scan-IP,原來的VIP還是保留，所以O(shè)racle里面的網(wǎng)絡配置要求還是很高的。拋開共享存儲，搭建的核心就是網(wǎng)絡配置了，網(wǎng)絡通則通。
scan-IP還可以繼續(xù)擴展，最多支持3個scan-ip,如下圖所示
當然網(wǎng)絡層面不只是這些，這方面的亮點Oracle就很專業(yè)了。我們有必要了解下TAF,在我的書中《Oracle DBA工作筆記》中，我這樣寫道：
TAF(Transparent Application Failover)是Oracle中對應用透明的故障轉(zhuǎn)移，在RAC環(huán)境中使用尤其廣泛。在RAC中Load Balance這塊確實做了很大的改進，從10g版本開始的多個VIP地址的Load Balance，到11g版本中的SCAN，做了很大的簡化。
而在Failover的實現(xiàn)中，還是有一定的使用限定，比如11g中默認的SCAN-IP的實現(xiàn)其實默認沒有Failover的選項，如果兩個節(jié)點中的其中一個節(jié)點掛了，那么原有的連接中繼續(xù)查詢就會提示session已經(jīng)斷開，需要重新連接。客戶端TAF主要會討論Failover Method和Failover Type的一些簡單內(nèi)容。
(1)Failover Method
Failover Method的主要思路就是換取故障轉(zhuǎn)移時間，或者換取資源來實現(xiàn)。
可以這樣來理解，假設(shè)我們存在兩個節(jié)點，如果某個session連接到了節(jié)點2，然而節(jié)點2突然掛了，為了更快處理Failover這種情況，F(xiàn)ailover Method有preconnect和basic兩種。
— preconnect這種預連接方式還是會占用較多的資源使用，在各個節(jié)點上會預先占用一部分額外的資源，在切換時會相對更加平滑，速度更快。
— basic這種方式，則在發(fā)生Failover時，再去切換對應的資源，中間會有一些卡頓，但是對于資源的消耗相對來說要小很多。
簡單來說，basic方式會在故障發(fā)生時才去判斷，而preconnect則是未雨綢繆;從實際的應用來說，basic這種方式更加通用，也是默認的故障轉(zhuǎn)移方式。
(2)Failover Type
Failover Type實現(xiàn)更加豐富而且靈活，非常強大。這個時候控制粒度可以針對用戶SQL的執(zhí)行情況進行控制，有select和session兩種;通過一個小例子說明一下。
比如，我們有個很大的查詢在節(jié)點2上進行，結(jié)果節(jié)點2突然掛了，對于正在執(zhí)行的查詢，比如說有10 000條數(shù)據(jù)，結(jié)果剛好故障發(fā)生的時候查出了8 000條，那么剩下的2 000該怎么處理。
***種方式就是使用select;即會完成故障切換，繼續(xù)把剩下的2 000條記錄返回，當然中間會有一些上下文環(huán)境的切換，對于用戶是透明的。
第二種方式是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，同樣也需要設(shè)置failover_mode和對應的類型。
RACDB =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = rac-scan)(PORT = 1521))
(CONNECT_DATA =
(SERVER = DEDICATED)
(SERVICE_NAME = RACDB)
)
)
從這個角度來看Oracle的方案真是精細。再來看看MySQL的方案。
分布式的方案，讓MySQL看起來像一把瑞士牛刀，對于網(wǎng)絡層面的要求，幾乎可以說MySQL沒有什么要求，申請一主一從，那么就只需要4個IP即可(主，從，VIP，MHA_Manager(考慮一個manager節(jié)點)),一主兩從是5個。
這一點上MySQL原生并不支持所謂的負載均衡，可以通過前端的業(yè)務來分流，比如使用中間件proxy,或者持續(xù)的拆分，達到一定的粒度后，通過架構(gòu)設(shè)計的方式來滿足需求。因為基于邏輯的復制，很容易擴展，一主多從都是很常見的，代價也不高，延遲不能說沒有，只是很低，能夠適應絕大部分的互聯(lián)網(wǎng)業(yè)務需求。
而說到觸發(fā)MHA切換的條件，從網(wǎng)絡層面來看，如下的紅點都是潛在的隱患，有的是網(wǎng)絡的中斷，有的是網(wǎng)絡的延遲，發(fā)生故障的時候，保數(shù)據(jù)還是保性能穩(wěn)定，都可以基于自己的需求來定制。從這一點上來說，丟失數(shù)據(jù)的概率是有的。絕對不是強一致性的無損復制。
整體來看兩種方案，RAC是集中共享，除了存儲層面的共享外，網(wǎng)絡層面的組播其實也會提高節(jié)點間通信的成本，所以RAC對于網(wǎng)絡的需求很大，如果存在延遲是很危險的，發(fā)生了腦裂就很尷尬了。MySQL MHA的方案是分布式的。支持大批量的環(huán)境，節(jié)點間通信的成本相對來說要低很多。但是從數(shù)據(jù)架構(gòu)的角度來說，因為是復制的數(shù)據(jù)分布方式，所以對于存儲盡管不是共享存儲，但是對于存儲的成本還是高于RAC(不是說存儲的價格，是存儲的數(shù)據(jù)量大小).
