RAC與雙機(jī)熱備的區(qū)別

RAC與雙機(jī)熱備的區(qū)別。Cluster()多機(jī)系統(tǒng)平臺(tái)上，常用的高可用性技術(shù)有兩種：雙機(jī)熱備份和RAC并行服務(wù)器。這兩種方式采用的機(jī)制不同，實(shí)現(xiàn)的效果也不同。1、雙機(jī)熱備份方式(器無(wú)法直接訪問(wèn)數(shù)據(jù)庫(kù)，自然也無(wú)法進(jìn)行負(fù)載分擔(dān)。當(dāng)服務(wù)器A由于故障失效時(shí)，由相應(yīng)的操作系統(tǒng)軟件控制，將服務(wù)器A()B控制，同時(shí)在服務(wù)器B上啟動(dòng)另一個(gè)數(shù)據(jù)庫(kù)進(jìn)程，管理數(shù)據(jù)庫(kù)。這種切換并啟動(dòng)新的數(shù)據(jù)庫(kù)核心的過(guò)程一般需要幾十秒到幾分鐘。這種方式的主要缺點(diǎn)在于：由于需要重新啟動(dòng)數(shù)據(jù)庫(kù)核心進(jìn)程，無(wú)法保證數(shù)據(jù)庫(kù)系統(tǒng)連續(xù)不間斷地運(yùn)行；連接和登錄工作；的問(wèn)題，但給系統(tǒng)管理、統(tǒng)計(jì)分析等業(yè)務(wù)處理帶來(lái)了很多額外的復(fù)雜性2、RAC方式()操作一個(gè)數(shù)據(jù)庫(kù)。客戶端無(wú)論連接到哪個(gè)服務(wù)器都可以在數(shù)據(jù)庫(kù)中進(jìn)行操作。當(dāng)服務(wù)器A由于故障失效時(shí)，數(shù)據(jù)庫(kù)系統(tǒng)本身并未停止工作，連接在服務(wù)器B上的客戶端還可以繼續(xù)進(jìn)行正常工作。同時(shí)，服務(wù)器B上也不需要再啟動(dòng)新的數(shù)據(jù)庫(kù)服務(wù)器進(jìn)程，因此也沒(méi)有“切換時(shí)間”。對(duì)于一些特殊應(yīng)用中嚴(yán)格要求前端應(yīng)用不能中斷的情況，Oracle并行服務(wù)器還提供了一種“預(yù)連接(pre-connect)”方式，以這種方式連接的客戶端當(dāng)服務(wù)器端發(fā)生故障時(shí)，客戶端與數(shù)據(jù)庫(kù)服務(wù)器的連接不會(huì)中斷，會(huì)被Oracle并行服務(wù)器軟件自動(dòng)轉(zhuǎn)接到還在正常工作的其它服務(wù)器上，不需要重新輸入用戶名及口令。同樣有許多操作系統(tǒng)平臺(tái)支持并行服務(wù)器方式的高可用性方案，例如HPMCServiceGuardOPSEdition等。與雙機(jī)熱備份方式相比，OracleRealApplicationCluster并行服務(wù)器方式有以下優(yōu)點(diǎn)：割簡(jiǎn)化了開(kāi)發(fā)的復(fù)雜程度，同時(shí)今后系統(tǒng)擴(kuò)展也無(wú)需修改應(yīng)用程序不需要重新啟動(dòng)數(shù)據(jù)庫(kù)核心進(jìn)程，縮短了故障造成的停機(jī)時(shí)間3、RAC的好處CacheFusionOracleRealApplicationClusters為企業(yè)應(yīng)用開(kāi)發(fā)提供了以下好處：對(duì)數(shù)據(jù)進(jìn)行分區(qū)。對(duì)于所有的應(yīng)用即時(shí)提供集群的可伸縮性－－不用修改應(yīng)用程序。力，使部件失敗屏蔽開(kāi)最終用戶。單獨(dú)的管理實(shí)體；為了進(jìn)行所有管理操作，在集群中保持一個(gè)單獨(dú)的系統(tǒng)映像。DBAOracle將管理功能自動(dòng)分配到適DBA只管理著一個(gè)虛擬服務(wù)器。CacheFusionOracleOracle的投資。所有單節(jié)點(diǎn)Oracle接口連接到數(shù)據(jù)庫(kù)上?？缮炜s性RAC應(yīng)用的用戶或者中間層應(yīng)用服務(wù)器客戶，可以通過(guò)虛擬數(shù)據(jù)庫(kù)服務(wù)名連接到數(shù)據(jù)庫(kù)OracleRealApplicationClusters數(shù)據(jù)庫(kù)實(shí)例預(yù)訂所有數(shù)據(jù)庫(kù)服務(wù)或者部分子集數(shù)據(jù)庫(kù)服務(wù)。這使得DBA高度靈活地選定，連接到特定數(shù)據(jù)庫(kù)服務(wù)的特定應(yīng)用程序客戶是否可以連接到某些或者全部的數(shù)據(jù)庫(kù)節(jié)點(diǎn)。雖然每一個(gè)節(jié)點(diǎn)IP地址時(shí)，應(yīng)用客戶仍可以在一個(gè)邏輯數(shù)據(jù)庫(kù)服務(wù)名的水平上進(jìn)行連接。因此客戶端對(duì)于不相關(guān)的事情如多服務(wù)器的多個(gè)地址可以毫不關(guān)心。隨著業(yè)務(wù)的增長(zhǎng)，應(yīng)用系統(tǒng)可以CacheFusionCPUDBA無(wú)需用手工對(duì)數(shù)據(jù)重新分區(qū)。這個(gè)優(yōu)點(diǎn)是這種體系結(jié)構(gòu)的副產(chǎn)品，因?yàn)橛型该鞫鹊臄?shù)據(jù)存取是CacheFusionCacheFusion體系機(jī)構(gòu)自動(dòng)適應(yīng)快速變化的應(yīng)用需求及隨之而來(lái)的工作DBARealApplicationClusters通過(guò)動(dòng)態(tài)地重新分配數(shù)據(jù)庫(kù)資源，從而在節(jié)點(diǎn)之間用最小化的磁盤I/O和低的延遲通信來(lái)RealApplicationClusters可以從容實(shí)現(xiàn)增加的應(yīng)用吞吐量和優(yōu)化的響應(yīng)時(shí)間。高可用性RealApplicationClusters提供了真正的高可用性解決方案，關(guān)鍵的突破是在大多數(shù)數(shù)據(jù)庫(kù)恢復(fù)RealApplicationClusters24x7可用性的最佳平臺(tái)。RealApplicationClusters在高可用性上在三個(gè)關(guān)鍵領(lǐng)域勝出：提供了數(shù)據(jù)庫(kù)恢復(fù)期間的數(shù)據(jù)塊訪問(wèn)透明的失效轉(zhuǎn)移對(duì)最終用戶屏蔽了系統(tǒng)失效N-1節(jié)點(diǎn)失效的容錯(cuò)能力只要有一個(gè)數(shù)據(jù)庫(kù)節(jié)點(diǎn)幸存，RealApplicationClusters就能夠提供完全的數(shù)據(jù)庫(kù)訪問(wèn)和相對(duì)不間斷的操作?？晒芾硇訰ealApplicationClusters實(shí)現(xiàn)了真正意義上的一個(gè)單系統(tǒng)訪問(wèn)數(shù)據(jù)庫(kù)，它提供了從任何節(jié)點(diǎn)到所有磁盤設(shè)備和遠(yuǎn)程高速緩存進(jìn)行無(wú)縫數(shù)據(jù)訪問(wèn)的能力。此單系統(tǒng)映像延伸到所有數(shù)據(jù)庫(kù)管理操作。安裝、配置、備份、升級(jí)以及監(jiān)控等操作只需進(jìn)行一次，然后會(huì)自動(dòng)發(fā)布到集群中所有節(jié)點(diǎn)上去。各種Oracle工具（如OracleUniversalInstaller、DatabaseConfigurationAssistant以及RecoveryManager）將發(fā)現(xiàn)集群數(shù)據(jù)塊中所有不同的節(jié)點(diǎn)并以它們?yōu)槟繕?biāo)分配給想得到的任務(wù)。通過(guò)為特定的管理操作選擇多個(gè)目標(biāo)節(jié)點(diǎn)，管理任務(wù)在數(shù)據(jù)庫(kù)集群中多個(gè)節(jié)點(diǎn)上執(zhí)行。這為應(yīng)用系統(tǒng)管理其環(huán)境帶來(lái)了極大的可伸縮性上的經(jīng)濟(jì)實(shí)惠。例如，向數(shù)據(jù)庫(kù)集群添加一個(gè)節(jié)點(diǎn)只會(huì)增加最小的管理任務(wù)。這樣，RealApplicationClusters支持在線商務(wù)應(yīng)用和決策支持之類的應(yīng)用，并且為數(shù)據(jù)訪問(wèn)和管理提供了單一的虛擬高性能服務(wù)器?？偨Y(jié)1、對(duì)于硬件來(lái)說(shuō)基本上一樣，共享存儲(chǔ)、光纖線（也有還用SCSI線的）、多臺(tái)小型機(jī)（可以做多節(jié)點(diǎn)的相互熱備，也可以做多節(jié)點(diǎn)的RAC）、光纖交換機(jī)（如果是用光纖卡的話）；但做RAC，在主機(jī)之間，最好使用高帶寬網(wǎng)絡(luò)交換機(jī)（雖然不用也可以做成），硬件成本相差不大。2、軟件呢，差別可不小。如果是雙機(jī)熱備，必須買操作系統(tǒng)級(jí)的雙機(jī)管理軟件；如果是RAC前還是建議購(gòu)買雙機(jī)管理軟件（10gcrs+asmASM目前實(shí)在太難伺候了），RAClicense。3、日常維護(hù)。RAC要求的技術(shù)含量更高，也應(yīng)該更勤快。最關(guān)鍵的是得買Oracle服務(wù)，否則遇到有些問(wèn)題（bug），你就比單機(jī)還不高可用了。4RAC的官方論述吧。如果能用好，確實(shí)是很有好處的。目前我們的40多downtime，另一方面可以說(shuō)就是提高了生產(chǎn)力。另，為什么RAC比雙機(jī)熱備切換快很多？我們先分析雙機(jī)熱備切換的步驟：假設(shè)A機(jī)是主機(jī)，B機(jī)是備機(jī)。當(dāng)A機(jī)發(fā)生故障時(shí)，集群軟件通知B機(jī)接管數(shù)據(jù)庫(kù)。接管過(guò)程如下：B,T1（B時(shí)間內(nèi)了，因?yàn)榭偸切枰獜腁umountBmount的。）BT2BmountT3BopenT4應(yīng)用重新連接上BT5所以切換時(shí)間T=T1+T2+T3+T4+T5(可能還有其它一些可以忽略不計(jì)的時(shí)間)。以上切換時(shí)間的計(jì)算是從集群軟件斷定A機(jī)已經(jīng)停機(jī)開(kāi)始計(jì)算，之前的時(shí)間不計(jì)。如果數(shù)據(jù)庫(kù)文件所在的磁盤已經(jīng)是共享文件系統(tǒng)，而且事先Bmount該文件系統(tǒng)，那么T1=0,否則T1可能需要十幾秒到2分鐘。T2OracleSGA1~2分鐘。T3視數(shù)據(jù)文件的數(shù)量而定，如果數(shù)據(jù)文件比較多，那么這個(gè)時(shí)間也會(huì)比較長(zhǎng)，一般2~5這個(gè)時(shí)間和磁盤的速度也有關(guān)系。shutdownopen時(shí)不需要做恢1分鐘之內(nèi)；但是如果是由于故障停機(jī)切換，那么數(shù)據(jù)庫(kù)重open(instancerecovery)T4110分鐘，甚至更長(zhǎng)。這個(gè)時(shí)間和磁盤的速度也有關(guān)系。如果應(yīng)用原來(lái)也跑在A署在獨(dú)立的應(yīng)用服務(wù)器，例如CIP地址浮動(dòng)到B機(jī)，Oracle監(jiān)聽(tīng)器重啟以后，應(yīng)用才能重新連接到數(shù)據(jù)庫(kù)服務(wù)器。這個(gè)時(shí)間可能需要15分鐘，重啟應(yīng)用的時(shí)間也可能更長(zhǎng)。所以雙機(jī)熱備下切換時(shí)間最少T=0+1+2+1+1=5分鐘，這是非常理想的情況下；按照經(jīng)驗(yàn)，至少需要10分鐘。也可能是T=2+2+5+10+5=24分鐘，甚至更長(zhǎng)，視數(shù)據(jù)庫(kù)需要恢復(fù)的時(shí)間。再看RAC的情況mountT1=0BOpenT2=0,T3=0,T4=0如果應(yīng)用原來(lái)只跑在A機(jī)上，那么為縮短停機(jī)時(shí)間，可以事先可以在B機(jī)B機(jī)的應(yīng)用即可。沒(méi)有停頓。如果應(yīng)用部署在獨(dú)立的應(yīng)用服務(wù)器上，例如C甚至還有D機(jī)時(shí)，原來(lái)連接B機(jī)的