摘要:Oracle數據庫在各種應用系統中負責存儲平臺全部的用戶數據,數據庫的可靠性及安全性直接影響平臺的安全運行,目前採用的Oracle Replication方式來實現的數據庫高可靠性已經顯示出了弊端,本文介紹並分析了目前比較流行的幾種數據庫高可用性的架構:Oracle Replication、Oracle Rac、Oracle 主機HA等,但願給你們一個參考。html
高可用(HA)性有兩種不一樣的含義,在廣義環境中是指整個系統的高可用性,在狹義方面通常指主機、服務的冗餘,如主機HA、應用程序的HA等,不管那種狀況,高可用性均可以包含以下一些方面:node
Ø 系統失敗或崩潰數據庫
Ø 應用層或者中間層錯誤緩存
Ø 網絡失敗安全
Ø 介質失敗:指一些存放數據的媒體介質故障服務器
Ø 人爲錯誤網絡
Ø 系統的容災備份架構
Ø 計劃內的維護或者重啓併發
可見,高可用性不只包含了系統自己故障、應用層的故障、網絡故障、認爲操做的錯誤等,還包含數據的冗餘、容災及計劃的維護時間等,也就是說一個真正的高可用環境,不只能避免系統自己的問題,還應該能防止天災、人禍,而且有一個可靠的系統升級及計劃維護操做。負載均衡
本文探討的Oracle 數據庫層面的高可用性,不可避免也會涉及到一些主機、存儲、操做系統方面的高可用性,由於要實現Oracle服務的連續性保障是離不開硬件層面的支持的。隨着Oracle技術的發展(Oralce 8i/9i/10g/11g),高可用性愈來愈完善、愈來愈可靠,本文介紹了四種Oracle 高可用性的相關產品,並經過其實現方式和性能的比較獲得在如今和將來的Vas2000系統中更適合的數據庫高可用性方案:
Ø Oracle Parallel Server/Oracle Real Application Cluster(Oracle Rac)
Ø Oracle Standby Database/Oracle Data Guard
Ø Oracle Advanced Replication/Oracle Stream
Ø Oracle Server HA
OPS 從Oracle 8i開始提供,從Oracle 9i開始成爲RAC,而且隨着高性能PC SERVER的普及,Oracle Rac也成爲Oracle高可用性產品最流行的一種架構,Oracle Rac經過組織多個服務器的Cluster來得到更大的計算處理能力和故障處理能力的集羣。
RAC經過不一樣的節點(node)使用一個(通常是一個)或者多個Oracle實例(Instance)與一個數據庫(Database)鏈接,該數據庫存放於多個節點的公用存儲(Share Storage)上,經過高速緩存合併技術使得集羣中的每一個節點能夠經過高速集羣互聯高效的同步其內存高速緩存,從而最大限度地減低磁盤IO,而且自動並行處理及均勻分佈負載,當其中一個節點發生故障時能夠自動容錯和恢復能力來實現節點的故障切換(Failover),從而保證數據庫7X24小時的高可用性,下圖1 是以兩個節點爲例來簡單介紹一個RAC架構的軟、硬件結構:
圖1 Oracle RAC結構圖
在上圖的結構中採用了2節點(node)的RAC,經過共享的存儲介質使兩個節點同時訪問Database,在實際的工做環境中共享存儲通常經過存儲網絡(SAN)提供,應用層服務器經過鏈接RAC的VIP(Virtual IP)負載均衡的鏈接到任何一個節點提供服務,當其中的任何一個節點發生故障時,另外一個正常的節點能夠自動接管其服務,對於應用來講不須要作任何切換,只需經過VIP的自動跳轉來實現失敗節點的切換,在故障切換時Oracle會自動恢復故障節點中的事物,以便使整個數據庫處於一致狀態,整個切換過程通常持續1~5分鐘,具體取決於應用環境的壓力大小和複雜程度。
Oracle RAC除了硬件的組成外,還須要Oracle的軟件組件來支持,主要包含以下5個層次的軟件環境:
Ø CRS:Oracle 10g以上版本的Cluster軟件,管理整個RAC環境,包括VIP、監聽、ASM、DB等,除了Oracle本身的Cluster軟件外,目前也有不少第三方的Cluster軟件可用,好比:Sun Cluster、Lifekeeper、Leagto等,能夠根據具體部署環境的要求來選擇
Ø RAC:Oracle的Cluster支持組件
Ø Listener:監聽與Oracle網絡
Ø ASM Inst:ASM的實例,提供存儲管理,使得存儲空間之間能夠提供給Cluster數據庫使用,在不少OS上若是使用了第三方的Cluster軟件則必須採用第三方的存儲管理軟件(LVM),如IBM的HACMP、Veritas的VCS等
DB Inst:這裏是RAC環境的最上層,DB層,數據庫就運行在該層
1) 單一的Cluster環境
從Oracle 10g開始推出的CRS軟件與ASM存儲管理設置,能夠徹底脫離第三方的Cluster軟件而在各個平臺上安裝使用,從而不但下降了RAC環境的成本,也使安裝、維護更加簡單
2) 實現Oracle的持續服務和負載均衡
經過VIP訪問RAC,當一個節點發生故障時這個VIP會轉移到其餘節點上,從而保證應用的不間斷服務,同時CRS也能夠對訪問RAC的服務負載均衡的分佈到環境中的每一個node上。RAC環境也是一個可伸縮的環境,在不影響當前業務的條件下,能夠方便的增長和刪除節點。
3) 在線補丁升級
RAC系統支持補丁滾動方式的升級,當補丁應用大一個節點上時其餘節點能夠正常的運行提供服務,同時根據補丁產生的編號,將不定標記爲是不是否做爲滾動升級來安裝,若是須要滾動升級則能夠在不影響提供服務的前提下自動應用到每一個節點。
4) 須要與其餘容災組件配合完成存儲的備份
RAC的Data file、Control file、Redo log等都存放到共享的存儲上,RAC只具有主機、應用的保護和負載均衡,並不具有容災的功能,如共享磁盤設備損壞或者不可預料的損失將致使RAC環境的不可以使用,因此RAC通常要與其餘的容災組件配合使用來保證數據的安全,通常依靠RAID、LV鏡像、活Data Gua來實現數據的冗餘。
Standby database/Data Guard是Oracle退出的另外一種高可用性數據庫方案,在主要和備用節點之間經過日誌同步來保證數據同步,備用節點做爲主節點的備份,能夠實現快速的切換與災難性恢復。從Oralce 9i開始,Standby數據庫改名爲數據庫保護(Data Guard)
Data Guard通常包括兩套數據庫環境,一臺主要數據庫,一臺備用數據庫,與RAC不一樣的是,以通常狀況下只有一個節點處於活動狀態,全部應用都鏈接到主服務器上,只有當主服務器發送故障時才考慮切換到備用服務器。備用服務器通常不提供讀寫的操做,只有當須要時才提供只讀的操做,或者當主站點出現故障時通過切換操做才變爲主數據庫,提供正常的讀寫操做,因爲存在Active/Standby兩套主機、存儲環境,因此較RAC多了數據保護盒容災的功能,圖2爲Data Guard的結構圖:
圖2 Oracle Data Guard結構圖
在以上結構中,主備數據庫各一套,在實際的應用環境中能夠根據環境的不一樣配置多套主、備用數據庫。物理Standby實際上是採用備份與恢復的原理實現的,在主、備數據庫之間,採用Standby的日誌傳送方式,歸檔日誌活聯機日誌經過網絡傳送到備用端,因此能夠把Standby看作是一個正在不停恢復中的數據庫,由於主數據庫一直在運行,因此備用數據庫一直處於應用日誌狀態,或者等待下一個日誌應用。由於Standby的主數據庫與備用數據庫是兩個獨立的數據庫,基本上沒有太大的聯繫,因此該體系結構遠沒有RAC那麼複雜,只要兩個數據庫直接網絡相通就能夠。從Oracle 9i開始,既能夠傳送歸檔日誌也能夠傳送聯機日誌,根據傳送日誌的不一樣分別由ARCH和LGWR進程來處理,但因爲傳送聯機日誌須要實時的同步,因此要求在備用數據庫創建對應的日誌文件(Standby log),而且可能會對LGWR進程形成必定的影響,因此從Oracle 10g之後默認採用歸檔日誌傳送,這種方式不須要額外的配置,只須要簡單的修改Standby數據庫的歸檔路徑便可。
1) 能夠實現數據庫主機及存儲的徹底冗餘保護,該冗餘甚至能夠跨地域作成容災保護,是Oracle主推的容災產品。在Standby中主用數據庫必須運行在歸檔模式下,以保證備用節點的數據一致性,所以該特性並不適合數據倉庫。
2) Standby主節點對OS的環境要求較高,通常要必須是相同或者相近的OS環境,而且對數據庫版本也有特定的要求,不能實現跨數據庫版本的備份。
3) 不能自動的故障切換,若是主站點損壞要切換到備用站點,則須要在切換前徹底同步主站點當前的聯機日誌,不然會發生切換後數據丟失的現象。
Advanced Replication/Streams的設計目的是更靈活的實現數據分佈,這種技術能夠講一個數據庫中的表、用戶(Schema)、表空間(Tablespace)或者整個數據庫複製到另外一數據庫上中,甚至是雙向的同步,Oracle 9iR2開始實現這種方式更傾向於Streams技術,Advanced Replication是基於內部觸發器的技術,而Streams採用挖掘日誌的方式,對系統的壓力大大的減少。
在Oracle 9iR2以前,若是想實現數據庫的複製,除了備用數據庫(Standby Database)和高級複製(Advanced Replication)等技術外,沒有其餘號的辦法,而Standby Database主要應用於容災,是這個數據庫的徹底複製,而Advanced Replication配置相對複雜,而且對性能影響比較大,所以在應用上都有弊端,Oracle在9iR2版開始推出Streams技術,它與Standby備份數據庫技術內部運行機制很是類似,都是捕獲主數據庫的日誌而後傳送到目標機器上應用日誌而恢復,圖3是Streams技術的結構圖:
圖3Streams結構圖
雖然與Standby同樣都是捕獲主機的日誌後進行數據同步,但Streams技術卻比Standby具體不少優勢:
Ø 支持部分複製,能夠只複製一個表、一個用戶或者一個表空間,這個是Standby沒法實現的
Ø 支持一個數據庫內部複製也能夠跨數據庫複製甚至跨數據庫產品(從數據庫到非Oracle數據庫之間的複製
Ø 支持雙向複製,而Standby備用數據庫除了能提供查詢外在備用狀態下是不支持寫操做的
Streams技術經過高級隊列(Advanced Queuing)、日誌挖掘(Logminer)、和做業調度(Job Schedule)等技術,來實現集捕獲、傳輸、共享的數據共享通道。Streams Replication的處理過程主要分爲三個階段,包括:捕獲(Capture)、傳播(Propagate)與應用(Apply),下面咱們具體介紹這三個階段的工做原理:
Ø 捕獲:根據站點定義的捕獲規則(Rules),將符合捕獲的事物及操做(DML、DL)從數據庫的聯機日誌或者歸檔日誌中解析出來,變成邏輯改變記錄LCR(Logical Change Records)
Ø 傳播:主要是網絡傳播過程,做爲Job Queues進行調度,它負責將消息隊列中的LCRs傳送到目標隊列中,它提供了「一對多」、「多對一」、「一對一」的傳播方式,還支持不一樣環境中的傳播
應用:負責從目標站點消息隊列提早LCRs,而且根據Streams Replication目標站點定義的規則(Rules)解析出一句提交的事物,而後按照以來關係與執行順序來組織好這些事物分配給應用進程應用這些事物。
1) Oracle Streams最大的特色就是靈活,能夠跨平臺對單獨表、用戶、表空間或者整個數據庫進行復制,而複製的壓力更小,基本對數據庫形成額外的壓力,這也是對Advanced Replication更加先進的體現
2) Streams能夠實現雙向複製和多源複製,靈活的跟進應用特色定義複製的方式
3) 能夠實現數據庫主機、存儲的徹底容易備份,大大提升了系統的可用性、擴展性和安全性
4) Streams技術雖然獲得了很大的完善,但該技術缺乏像RAC、Data Guard技術那樣在高可用環境下的驗證,因此目前對該技術的認知度還有待提升
Oracle主機HA(Server HA)屬於咱們開始說的狹義意義上的HA,它是基於OS的技術,採用OS支持的Cluster Soft來保證主機的冗餘保護,當主機或者網絡發生故障時來實現自動保護切換,它和RAC同樣使用共享存儲來保證數據的一致性
主機HA技術出現的比較早,技術也比較成熟,如今市場上也有不少優秀的支持各類OS的Cluster Soft,因此主機HA技術應用很是普遍,並且主機HA的集羣技術與數據庫的版本、特性無關,在不一樣的數據庫版本甚至不一樣的數據庫上均可以實現主機的HA,它與RAC的工做模式有所不一樣,RAC主要工做在雙機雙工的末實現,而主機HA則工做在雙機熱備或者雙機互備的模式下,同時RAC是居於數據庫而完成的高可用性,而主機HA是基於OS完成的主機高可用性來保證數據庫的高可用性,圖4爲主機HA的結構圖:
圖4 主機HA結構圖
主機HA技術是一個或者多個主機共享一臺備用主機的集羣技術,因此它能解決主機故障包括OS故障、主機網卡故障、單個主機的網絡故障等,經過Cluster軟件將兩臺或者多臺數據庫主機綁定一個服務IP,全部的Data file、Contr File、Redo log等都存放於共享的存儲上,主機HA集羣經過一個服務IP對外提供服務,經過HA Soft軟件的管理集羣中的各個主機運行在Active/Standby方式下,當其中一臺主機發送故障時,HA Soft軟件會自動的檢測到故障而且將提供服務的IP切換到正常的主機上提供服務,從而保證了數據庫服務的連續性和故障的自動切換。如今支持主機HA的Cluster軟件有不少種,只要的有:Veritas的VCS,IBM的HACMP,HP的ServiceGuard,SUN的Sun Cluster等。
1) 主機HA的最大優勢就是能夠解決服務器的單點故障,Database全部的文件都創建在共享存儲上,存儲的冗餘須要依賴其餘技術(RAID、LVS等)來實現
2) 主機HA的技術簡單成熟,因此在實際的應用中被廣使用,但對主機資源的浪費比較嚴重,基本上要保證對等的資源處於等待狀態
Oracle數據庫的穩定與安全關乎整個平臺的穩定與安全,下圖描述的體系結構是實現Oracle高可靠性的一種不錯的架構,數據庫採用了RAC+ASM+STANDBY的結構體系,應用層採用Oracle本身的Application Server。用戶經過負載均衡設備訪問不一樣的Oracle應用服務器,而應用服務器經過自動負載均衡及Failover特性訪問當前的主數據庫。
當主站點出現故障的時候,Data guard能夠手工或者是自動切換到備用端,應用服務器的訪問也將自動被切換到備用站點,以保證系統的最大可用性與業務連續性。
以上咱們介紹了當今世界上流行的Oracle 高可用性的架構方案,但對於咱們現實的工做中,隨業務的不斷髮展,根據硬件的投入與產出的比例,平臺到底適合哪一種數據庫的高可用性方案比較合適呢?我認爲能夠根據平臺業務、硬件配置的不一樣選擇不一樣的數據庫高可用性方案,從而既極大的發揮了平臺中硬件設備的性能同時也保證了數據的冗餘,主要可依據現網數據庫主機的配置和對數據庫訪問的併發需求來選擇,具體以下:
1) 現網兩臺數據庫主機配置至關而且數據庫併發訪問量較大
對於這種平臺因爲數據庫訪問量相對較大,而且數據庫主機的硬件配置至關,建議採用Oracle Advanced Replication/Streams的架構來實現數據庫的高可用性,這樣兩臺數據庫服務器都做爲主用服務器提供服務,在保證了併發數的同時又保證數據的冗餘備份。
2) 現網數據庫主機性能較低但須要支持大量的併發訪問
對於這種平臺建議採用Oracle RAC的架構方案,該方案可使多臺鏈接的PC組成一個支持大量訪問的集羣,而且能夠靈活的增長、刪除集羣中的節點來實現平臺的平滑擴容和升級,但須要相應的存儲、容災方案的配合。
3) 現網只有一臺數據庫主機而且該主機基本知足平臺需求
對於這種平臺建議採用備用數據的方案(Standby/Data Guard),一臺性能不錯的主機做爲主數據庫,增長一條檔次較低的主機(pc server)做爲備用數據庫,備用數據庫只作主用數據庫的冗餘,不提供讀寫操做,在主用數據庫發生故障時能夠臨時啓用備用數據庫提供服務。