關(guān)于Oracle和MySQL的高可用方案，其實(shí)一直想要總結(jié)了，就會(huì)分為幾個(gè)系列來簡(jiǎn)單說說。通過這樣的對(duì)比，會(huì)對(duì)兩種數(shù)據(jù)庫架構(gòu)設(shè)計(jì)上的細(xì)節(jié)差異有一個(gè)基本的認(rèn)識(shí)。Oracle有一套很成熟的解決方案。用我在OOW上的ppt來看，是MAA的方案,今年是這個(gè)方案的16周年了。

而MySQL因?yàn)殚_源的特點(diǎn)，社區(qū)里推出了更多的解決方案，個(gè)人的見解，InnoDB Cluster會(huì)是MySQL以后的高可用方案標(biāo)配。

而目前來看，MGR固然不錯(cuò)，MySQL Cluster方案也有，PXC,Galera等方案，個(gè)人還是更傾向于MHA.

所以本文會(huì)分為幾個(gè)部分來解讀，先拿RAC和MHA來做一個(gè)基本的對(duì)比。

Oracle的解決方案在阿里快速發(fā)展時(shí)期支撐起了核心業(yè)務(wù)的需求。大概是這樣的架構(gòu)體系，看起來很龐大。里面的RAC算是一個(gè)貴族，用昂貴的商業(yè)存儲(chǔ)，網(wǎng)絡(luò)帶寬要求極高，前端大量的小機(jī)業(yè)務(wù)還有不菲的licence費(fèi)用。非常典型的IOE的經(jīng)典架構(gòu)。

如果要考慮異地容災(zāi)，那么資源配置要double,預(yù)算翻番。

MySQL的架構(gòu)方案相對(duì)來說更加平民化，普通的pc就可以，但是數(shù)量級(jí)要高，做業(yè)務(wù)拆分，水平拆分就能夠橫向擴(kuò)展出非常多的節(jié)點(diǎn)，很多大互聯(lián)網(wǎng)公司的MySQL集群規(guī)模都是幾百幾百的規(guī)模，上千都不稀奇。如此之多的服務(wù)資源，發(fā)生故障的概率還是有的，保證業(yè)務(wù)服務(wù)的可持續(xù)性訪問，是技術(shù)方案的關(guān)鍵。如果按照MHA的架構(gòu)，基本上就是MHA Manager節(jié)點(diǎn)來負(fù)責(zé)整個(gè)集群的狀態(tài)，好比一個(gè)居委會(huì)大媽，對(duì)住戶的大大小小的事情都了如指掌包打聽。

當(dāng)然上面的說法過于籠統(tǒng)，我們從一些細(xì)節(jié)入手。比如先來說說網(wǎng)絡(luò)的事情。

Oracle對(duì)于網(wǎng)絡(luò)的要求還是很嚴(yán)格的，一般都是要2塊物理網(wǎng)卡，每臺(tái)服務(wù)器需要至少3個(gè)IP, Public IP,private IP,VIP，除了共享存儲(chǔ)，至少需要2個(gè)計(jì)算節(jié)點(diǎn)。

private IP是節(jié)點(diǎn)間互信的，Public IP和VIP在一個(gè)網(wǎng)段，簡(jiǎn)單來說，VIP是對(duì)外的，是public IP所在網(wǎng)絡(luò)的漂移IP，在10g里面都是通過VIP來做負(fù)載均衡的，11g開始有了scan-IP,原來的VIP還是保留，所以O(shè)racle里面的網(wǎng)絡(luò)配置要求還是很高的。拋開共享存儲(chǔ)，搭建的核心就是網(wǎng)絡(luò)配置了，網(wǎng)絡(luò)通則通。

scan-IP還可以繼續(xù)擴(kuò)展，最多支持3個(gè)scan-ip,如下圖所示

當(dāng)然網(wǎng)絡(luò)層面不只是這些，這方面的亮點(diǎn)Oracle就很專業(yè)了。我們有必要了解下TAF,在我的書中《Oracle DBA工作筆記》中，我這樣寫道：

TAF(Transparent Application Failover)是Oracle中對(duì)應(yīng)用透明的故障轉(zhuǎn)移，在RAC環(huán)境中使用尤其廣泛。在RAC中Load Balance這塊確實(shí)做了很大的改進(jìn)，從10g版本開始的多個(gè)VIP地址的Load Balance，到11g版本中的SCAN，做了很大的簡(jiǎn)化。

而在Failover的實(shí)現(xiàn)中，還是有一定的使用限定，比如11g中默認(rèn)的SCAN-IP的實(shí)現(xiàn)其實(shí)默認(rèn)沒有Failover的選項(xiàng)，如果兩個(gè)節(jié)點(diǎn)中的其中一個(gè)節(jié)點(diǎn)掛了，那么原有的連接中繼續(xù)查詢就會(huì)提示session已經(jīng)斷開，需要重新連接?？蛻舳薚AF主要會(huì)討論Failover Method和Failover Type的一些簡(jiǎn)單內(nèi)容。

(1)Failover Method

Failover Method的主要思路就是換取故障轉(zhuǎn)移時(shí)間，或者換取資源來實(shí)現(xiàn)。

可以這樣來理解，假設(shè)我們存在兩個(gè)節(jié)點(diǎn)，如果某個(gè)session連接到了節(jié)點(diǎn)2，然而節(jié)點(diǎn)2突然掛了，為了更快處理Failover這種情況，F(xiàn)ailover Method有preconnect和basic兩種。

— preconnect這種預(yù)連接方式還是會(huì)占用較多的資源使用，在各個(gè)節(jié)點(diǎn)上會(huì)預(yù)先占用一部分額外的資源，在切換時(shí)會(huì)相對(duì)更加平滑，速度更快。

— basic這種方式，則在發(fā)生Failover時(shí)，再去切換對(duì)應(yīng)的資源，中間會(huì)有一些卡頓，但是對(duì)于資源的消耗相對(duì)來說要小很多。

簡(jiǎn)單來說，basic方式會(huì)在故障發(fā)生時(shí)才去判斷，而preconnect則是未雨綢繆;從實(shí)際的應(yīng)用來說，basic這種方式更加通用，也是默認(rèn)的故障轉(zhuǎn)移方式。

(2)Failover Type

Failover Type實(shí)現(xiàn)更加豐富而且靈活，非常強(qiáng)大。這個(gè)時(shí)候控制粒度可以針對(duì)用戶SQL的執(zhí)行情況進(jìn)行控制，有select和session兩種;通過一個(gè)小例子說明一下。

比如，我們有個(gè)很大的查詢?cè)诠?jié)點(diǎn)2上進(jìn)行，結(jié)果節(jié)點(diǎn)2突然掛了，對(duì)于正在執(zhí)行的查詢，比如說有10 000條數(shù)據(jù)，結(jié)果剛好故障發(fā)生的時(shí)候查出了8 000條，那么剩下的2 000該怎么處理。

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

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

在10g版本中借助于VIP的配置達(dá)到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也想進(jìn)一步擴(kuò)展Failover，同樣也需要設(shè)置failover_mode和對(duì)應(yīng)的類型。
RACDB =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = rac-scan)(PORT = 1521))
(CONNECT_DATA =
(SERVER = DEDICATED)
(SERVICE_NAME = RACDB)
)
)

從這個(gè)角度來看Oracle的方案真是精細(xì)。再來看看MySQL的方案。

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

這一點(diǎn)上MySQL原生并不支持所謂的負(fù)載均衡，可以通過前端的業(yè)務(wù)來分流，比如使用中間件proxy,或者持續(xù)的拆分，達(dá)到一定的粒度后，通過架構(gòu)設(shè)計(jì)的方式來滿足需求。因?yàn)榛谶壿嫷膹?fù)制，很容易擴(kuò)展，一主多從都是很常見的，代價(jià)也不高，延遲不能說沒有，只是很低，能夠適應(yīng)絕大部分的互聯(lián)網(wǎng)業(yè)務(wù)需求。

而說到觸發(fā)MHA切換的條件，從網(wǎng)絡(luò)層面來看，如下的紅點(diǎn)都是潛在的隱患，有的是網(wǎng)絡(luò)的中斷，有的是網(wǎng)絡(luò)的延遲，發(fā)生故障的時(shí)候，保數(shù)據(jù)還是保性能穩(wěn)定，都可以基于自己的需求來定制。從這一點(diǎn)上來說，丟失數(shù)據(jù)的概率是有的。絕對(duì)不是強(qiáng)一致性的無損復(fù)制。

整體來看兩種方案，RAC是集中共享，除了存儲(chǔ)層面的共享外，網(wǎng)絡(luò)層面的組播其實(shí)也會(huì)提高節(jié)點(diǎn)間通信的成本，所以RAC對(duì)于網(wǎng)絡(luò)的需求很大，如果存在延遲是很危險(xiǎn)的，發(fā)生了腦裂就很尷尬了。MySQL MHA的方案是分布式的。支持大批量的環(huán)境，節(jié)點(diǎn)間通信的成本相對(duì)來說要低很多。但是從數(shù)據(jù)架構(gòu)的角度來說，因?yàn)槭菑?fù)制的數(shù)據(jù)分布方式，所以對(duì)于存儲(chǔ)盡管不是共享存儲(chǔ)，但是對(duì)于存儲(chǔ)的成本還是高于RAC(不是說存儲(chǔ)的價(jià)格，是存儲(chǔ)的數(shù)據(jù)量大小).