關(guān)于Oracle和MySQL的高可用方案，其實(shí)一直想要總結(jié)了，今天分為幾個(gè)系列簡(jiǎn)單說(shuō)說(shuō)。通過(guò)這樣的對(duì)比，會(huì)對(duì)兩種數(shù)據(jù)庫(kù)架構(gòu)設(shè)計(jì)上的細(xì)節(jié)差異有一個(gè)基本的認(rèn)識(shí)。

高可用方案概覽

Oracle有一套很成熟的高可用解決方案MAA。用我在OOW上的ppt來(lái)看，這個(gè)方案自9i開始，到今年已經(jīng)有16個(gè)年頭了。 

當(dāng)然，MAA方案雖好，成本還是有的、復(fù)雜度還是有的，所以放眼國(guó)內(nèi)的使用情況，RAC不一定是100%有，電信、證券、壽險(xiǎn)、銀行如果用，基本都是全套方案，有些相對(duì)保守，RAC也有使用active-passive模式的，互聯(lián)網(wǎng)行業(yè)如果用，清一色都是單實(shí)例和DG結(jié)合。

而MySQL因?yàn)殚_源的特點(diǎn)，官方和社區(qū)里推出了很更多的解決方案，高可用情況大體如下，僅供參考(數(shù)據(jù)引用自Percona)。 

因?yàn)闀r(shí)間的原因，MGR剛推出不久，還在觀察期。MGR固然不錯(cuò)，MySQL Cluster方案也有PXC、Galera等方案，個(gè)人還是更傾向于MHA。

基本情況說(shuō)完了，接下來(lái)分為幾個(gè)部分來(lái)解讀。

Oracle RAC和MySQL MHA 

先拿RAC和MHA來(lái)做一個(gè)基本的對(duì)比。

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

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

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

當(dāng)然上面的架構(gòu)圖過(guò)于籠統(tǒng)，在MHA的高版本里面還使用了binlogServer，我們從一些細(xì)節(jié)入手。比如先來(lái)說(shuō)說(shuō)網(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)單來(lái)說(shuō)，VIP是對(duì)外的，是public IP所在網(wǎng)絡(luò)的漂移IP，在10g里面都是通過(guò)VIP來(lái)做負(fù)載均衡的，11g開始有了scan-IP，原來(lái)的VIP還是保留，所以O(shè)racle里面的網(wǎng)絡(luò)配置要求還是很高的。拋開共享存儲(chǔ)，搭建的核心就是網(wǎng)絡(luò)配置了，網(wǎng)絡(luò)通則通。

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

當(dāng)然網(wǎng)絡(luò)層面不只是這些，我們還有必要了解下TAF(Transparent Application Failover)。TAF是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í)間，或者換取資源來(lái)實(shí)現(xiàn)。

可以這樣來(lái)理解，假設(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ì)來(lái)說(shuō)要小很多。

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

(2)Failover Type

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

比如，我們有個(gè)很大的查詢?cè)诠?jié)點(diǎn)2上進(jìn)行，結(jié)果節(jié)點(diǎn)2突然宕機(jī)了，對(duì)于正在執(zhí)行的查詢，比如說(shuō)有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è)角度來(lái)看，Oracle的方案真是精細(xì)。

再來(lái)看看MySQL的方案。

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

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

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

把上面的圖放大，其實(shí)會(huì)有更多的細(xì)節(jié)，比如ssh的連接檢測(cè)和數(shù)據(jù)庫(kù)的心跳檢測(cè)(insert_ping)，在整個(gè)方案里面要考慮的場(chǎng)景就很多了。對(duì)于網(wǎng)絡(luò)的切換，目前MHA做的主要是保證數(shù)據(jù)復(fù)制關(guān)系，如果要深入使用，還是要做更多的定制，比如結(jié)合Proxy的方案，使用ZooKeeper的狀態(tài)檢測(cè)，使用keepalive或者VIP的網(wǎng)絡(luò)層面的切換等。

整體來(lái)看兩種方案，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ì)來(lái)說(shuō)要低很多。但是從數(shù)據(jù)架構(gòu)的角度來(lái)說(shuō)，因?yàn)槭菑?fù)制的數(shù)據(jù)分布方式，所以對(duì)于存儲(chǔ)盡管不是共享存儲(chǔ)，對(duì)于存儲(chǔ)的成本還是高于RAC(不是說(shuō)存儲(chǔ)的價(jià)格，是存儲(chǔ)的數(shù)據(jù)量大小)。

Oracle Data Guard和MySQL災(zāi)備 

然后我們來(lái)繼續(xù)說(shuō)說(shuō)災(zāi)備的部分。我就拿Oracle的DG和MySQL的方案對(duì)比。

在災(zāi)備的概念中，Oracle DBA習(xí)慣叫做主備，即為Primary、Standby，而MySQL更喜歡叫做主從，即為Master、Slave，無(wú)論怎么叫，說(shuō)得都是同一個(gè)意思。

首先在Oracle中，數(shù)據(jù)是基于物理復(fù)制(此處說(shuō)的都是physical standby)，所以對(duì)于數(shù)據(jù)庫(kù)的狀態(tài)和角色就很好定位，從庫(kù)正常狀況下是無(wú)法讀寫的。所以在Oracle中角色轉(zhuǎn)換的概念就很清晰，failover和switchover，failover就是故障轉(zhuǎn)義，switchover就是主備切換。在MySQL中failover的概念很好理解，但是switchover相比來(lái)說(shuō)，就會(huì)淡化很多。

Oracle因?yàn)槭腔谖锢韽?fù)制，所以一直以來(lái)備庫(kù)要么就是恢復(fù)狀態(tài)(recover)，要么就是只讀不應(yīng)用狀態(tài)(read_only)，直到11g這個(gè)問(wèn)題才解決，就是大名鼎鼎的ADG(read only with apply)。而在MySQL里面這都不是事兒，備庫(kù)可以靈活的開關(guān)read_only的參數(shù)，當(dāng)然一般是不希望備庫(kù)寫入的,讀絕對(duì)不是問(wèn)題，而且還可以擴(kuò)展著讀，做讀寫分離。

對(duì)于Oracle的備庫(kù)的理解，我認(rèn)為除了ADG之外，最有亮點(diǎn)的就是閃回?cái)?shù)據(jù)庫(kù)了，可能很多Oracle DBA都對(duì)于閃回?cái)?shù)據(jù)庫(kù)敬而遠(yuǎn)之，技術(shù)的更新很多，好端端的特性放著不用太可惜了，比如搭建DG，分分鐘DG Broker搞定，使用手工方式不見得有多高效。

閃回的概念在MySQL里面也有，目前來(lái)說(shuō)，可以根據(jù)binlog抽取的數(shù)據(jù)做到DML的閃回，和Oracle里面的閃回差距還很大。Oracle里面的閃回五花八門，零零總總算下，差不多就有這些。

當(dāng)然常用、實(shí)用的不見得這么多，MySQL的DML還算是原生態(tài)，可以根據(jù)binlog抽取來(lái)恢復(fù)，或根據(jù)第三方工具輔助，但DDL就是難上加難了，目前MariaDB的DDL閃回就是一個(gè)突破，從我的理解來(lái)說(shuō)，應(yīng)該能夠?qū)崿F(xiàn)一部分的閃回功能，具體的效果我后面測(cè)試一下。

所以說(shuō)閃回是個(gè)大寶藏，到底有多好呢，Oracle的備庫(kù)方案有了快照數(shù)據(jù)庫(kù)，就是物理備庫(kù)可以臨時(shí)寫入，帶來(lái)的優(yōu)點(diǎn)就是主庫(kù)的碎片，在備庫(kù)是完全一樣的。所以在SQL審核方面有著得天獨(dú)厚的優(yōu)勢(shì)，我在線上的很多DDL審核中都做過(guò)測(cè)試和實(shí)際應(yīng)用，效果很贊，而且11g中的閃回可以在線開在線關(guān)，所以一般10g里面我建議要慎重使用，11g有條件下備庫(kù)端還是推薦的，滿足需求就行。當(dāng)然閃回?cái)?shù)據(jù)庫(kù)不是萬(wàn)金油，有個(gè)別場(chǎng)景是不支持的，在此就不展開了。

對(duì)于災(zāi)備來(lái)說(shuō)，數(shù)據(jù)庫(kù)的切換是未雨綢繆的事情，那么到底備庫(kù)切換的檢查是否OK呢，Oracle里面有了DG Broker這么一個(gè)神器，還在新版本中做了很多不錯(cuò)的選項(xiàng)，比如新版本中有了validate的選項(xiàng)，可以檢測(cè)主備切換的條件是否滿足。下面是DG Broker的命令中多出來(lái)的validate命令，效果還是不錯(cuò)的。

此外，從高可用的角度來(lái)說(shuō)，如果在備庫(kù)存在連接，做switchover時(shí)，會(huì)話會(huì)持續(xù)保持，當(dāng)然會(huì)有短暫的卡頓。這也就是特色的會(huì)話保持特性。

Preserving Active Data Guard Application Connections

當(dāng)然在MySQL里面就不可理解了，切換別說(shuō)會(huì)話保持，卡頓的影響都微乎其微。因?yàn)镺racle基于物理復(fù)制的方式，物理一致性使得復(fù)制擴(kuò)展性很難，當(dāng)然也不是說(shuō)完全不能實(shí)現(xiàn)，比如cascade standby，可以級(jí)聯(lián)復(fù)制，到了12c改進(jìn)一版，就是Far Sync，號(hào)稱是零數(shù)據(jù)丟失，對(duì)于跨區(qū)域的數(shù)據(jù)中心來(lái)說(shuō)，會(huì)把延遲降到最低。 

如果從技術(shù)架構(gòu)的角度來(lái)看，部署的分布圖類似下面的形式，中間有遠(yuǎn)距離的數(shù)據(jù)傳輸，可以通過(guò)中間的節(jié)點(diǎn)來(lái)轉(zhuǎn)換，中間這個(gè)節(jié)點(diǎn)很特別，是不存數(shù)據(jù)的，只是保持一個(gè)內(nèi)存結(jié)構(gòu)，同步數(shù)據(jù)。

還有就是延遲，我測(cè)試過(guò)DG的延遲，和MySQL在基本相似的壓力情況下，Oracle基本上控制在0.1秒左右，MySQL的復(fù)制就會(huì)有一些延遲的放大。

所以總體看下來(lái)，Oracle的方案是一種很專業(yè)的解決方案，工具全，架構(gòu)相對(duì)復(fù)雜，數(shù)據(jù)同步是強(qiáng)一致性。所以在涉及交易的業(yè)務(wù)中對(duì)它更加偏愛。

再來(lái)看看MySQL方向的改進(jìn)。我們不比單機(jī)性能和延遲了，因?yàn)檫@個(gè)確實(shí)是有差距，而且硬拼也沒有太大的意義，我們從整體架構(gòu)角度來(lái)考慮，這些又是Oracle難以實(shí)現(xiàn)的地方。

首先說(shuō)下主從復(fù)制，MySQL是典型的邏輯復(fù)制，主庫(kù)端可以承載大批量的并發(fā)，但是性能瓶頸很明顯，主庫(kù)的并發(fā)最后落到文件上還是串行的，拋開日志傳輸進(jìn)程的開銷，最大的瓶頸就在于SQL_Thread的應(yīng)用延遲。就好比中午大家出去吃飯，前臺(tái)可以并發(fā)點(diǎn)很多的菜品，但后臺(tái)的廚師就好比是SQL_Thread，他得一道菜一道菜做啊。怎么能做得更快呢?比如你叫了5分蓋飯，他可以一次性炒出來(lái)，這樣就能夠大大提高效率，所以前臺(tái)的小姑娘也會(huì)建議你和其他人點(diǎn)一樣的菜，原因就一個(gè)字——快。這用在并行復(fù)制上就是類似的道理。MySQL 5.6沒法做到細(xì)粒度的并行復(fù)制，只能在庫(kù)級(jí)別，而在MySQL 5.7中可以做到表級(jí)別更細(xì)粒度的，這個(gè)改進(jìn)就很明顯了。 

所以延遲的問(wèn)題能夠解決，后續(xù)的擴(kuò)展就容易多了，MySQL的擴(kuò)展甚至可以做到指數(shù)級(jí)的擴(kuò)展方式，如果允許一些低延時(shí)，大量的讀請(qǐng)求就可以逐步分解。所以一主多從的架構(gòu)方式也是見怪不怪。

值得一提的是MHA的一主多從架構(gòu)中，如果多個(gè)從庫(kù)存在延遲，在切換的時(shí)候MHA會(huì)補(bǔ)齊差異的日志，這是MHA的一大亮點(diǎn)。

而MySQL的級(jí)聯(lián)復(fù)制就更純粹了，和Oracle相比的最大優(yōu)勢(shì)就是一個(gè)數(shù)據(jù)庫(kù)可以既是主庫(kù)也可以同時(shí)是從庫(kù)，起到承上啟下的作用。 

這種擴(kuò)展方式簡(jiǎn)直是酸爽，在一些跨數(shù)據(jù)中心的場(chǎng)景，允許一定延遲的情況下還是有用武之地。比如你需要從北美讀數(shù)據(jù)，可以從北美推送數(shù)據(jù)庫(kù)到香港或者新加坡，再推送到北京。有了這種方式就很容易擴(kuò)展。當(dāng)然在實(shí)時(shí)交易中還是存在一些瓶頸和缺陷。

展望和后續(xù)補(bǔ)充 

如果拋開具體的數(shù)據(jù)庫(kù)，整體來(lái)說(shuō)數(shù)據(jù)量和業(yè)務(wù)量到達(dá)一定程度都會(huì)碰到一系列的問(wèn)題。這些都是痛點(diǎn)也是難點(diǎn)，常見的問(wèn)題如下：

1. 單臺(tái)服務(wù)器無(wú)法承載已有的壓力
2. 數(shù)據(jù)庫(kù)單表容量越來(lái)越大
3. 大量的讀寫需求無(wú)法平衡
4. 資源如果擴(kuò)容，應(yīng)用改動(dòng)較大
5. 資源的負(fù)載沒法拆分，或者不易拆分

這時(shí)就需要擴(kuò)展，就需要匹配的解決方案，比如中間件的方案，有的解決了一些通用的問(wèn)題，有些側(cè)重于某一方面。比如需要考慮sharding來(lái)分片，讀寫分離來(lái)做分擔(dān)讀寫壓力，前端海量訪問(wèn)可以通過(guò)大量的水平擴(kuò)展來(lái)分擔(dān)。

從這個(gè)角度來(lái)說(shuō)，MySQL是以架構(gòu)和規(guī)模取勝，通過(guò)業(yè)務(wù)拆分和架構(gòu)拆分能夠?qū)崿F(xiàn)線性擴(kuò)展。而Oracle的擴(kuò)展性雖然沒有那么好，但從架構(gòu)和業(yè)務(wù)層面來(lái)說(shuō)也能做，這個(gè)后續(xù)有機(jī)會(huì)再細(xì)細(xì)說(shuō)一說(shuō)，可以擬一篇分布式方面的文章。

小結(jié) 

簡(jiǎn)單總結(jié)一下，高可用的方案選擇很多，各家有各家的需求，能定制的定制，能開源的開源。大道至簡(jiǎn)，只要滿足了需求，系統(tǒng)穩(wěn)定不背鍋，那就是最好的方案。