DB高可用方案

前言:

本方案書,是為了提供高可用的Oracle DB服務。達到在異常故障時,數據庫還可以對外提供服務。比較了RAC和DataGuard。

Oracle RAC

一、架構



Rac 簡易架構圖


解說:用戶發起請求到Application Server, Application Server(這裡可以理解為Bserver)。Application Server 會將數據庫連接請求發送至上圖兩個oracle db server。兩個Oracle Db Server背後共享同一份數據,這兩個db server同時對外提供服務,任意一個db server down機。原連接會轉發至另一存活的db server。數據通過光纖交換機,儲存到儲存介質。

數據庫可簡單理解為內存和儲存的組合,內存在db server中,數據在儲存介質中,如上圖ASM。如數據庫出現問題,基本也是內存或儲存問題。(這裡不考慮網絡故障)。如db主機故障,rac有多個實例,可以保證db服務不中斷。另一種顧慮,儲存出現故障,可以冗餘的儲存保證數據不丟失,如oracle的ASM,OCFS2,Raw devices等。

注意: RAC並不是1+1=2. 即Rac性能,並不是隨著db server 數量成正比增加,如設置不當,性能比單實例還低的情況也很常見。


Oracle DataGuard

Oracle DataGuard屬於Oracle自帶的資料同步功能,基本原理是將日誌從Primary資料庫傳輸到Standby資料庫,然後在Standby資料庫上應用這些日誌,從而使Standby資料庫與Primary資料庫保持同步。

一、架構


Datagurad簡易架構圖

二、Standby資料庫類型

Standby資料庫通常分兩類:邏輯standby和物理standby。

邏輯standby是通過接收primary資料庫的redo log並轉換成sql語句,然後在standby資料庫上執行SQL語句實現同步。

物理standby是通過接收並應用primary資料庫的redo log以介質恢復的方式實現同步,不僅文件的物理結構相同,連塊在磁片上的存儲位置都是一模一樣的。

三、保護模式

1.最大保護 (簡言之:Standby DB收到redo log,Primary DB才可提交,保證資料完全不丟失。不常用)

這種模式是預設的資料保護模式,在不影響來源資料庫性能的條件下提供盡可能高的數據保護等級。在該種模式下,一旦日誌資料寫到來源資料庫的連線日誌檔,事務即可提交,不必等待日誌寫到目標資料庫,如果網路頻寬充足,該種模式可提供類似於最大可用模式的資料保護等級。

2.最大可用性 (簡言之:默認是最大保護,異常時可自動切換最大性能模式。)

這種模式和"最大保護"基本上差不多。正常情況下,主備庫之間是同步的。當網路或者備庫出現問題時,不會影響到主庫的當機,主庫會自動轉換庫"最大性能"模式,等待備庫可用時,將歸檔傳輸到備庫做恢復。

3.最大性能

這種模式保證主庫性能最大化,主備庫之間資料是非同步傳輸的。即,主備日誌歸檔以後才會傳輸到備用庫,在備庫上使用歸檔日誌檔做恢復操作。

四、安裝條件

運行DataGuard需要具備以下幾個條件:

1、 在主庫和從庫的所有機器上必須安裝同一個版本的Oracle企業版。

2、 主庫必須運行在歸檔模式下。

3、 主庫和從庫的作業系統必須一樣(允許版本不同),從庫可以使用與主庫不同的目錄結構。


兩者比較:

Advantage of RAC:

High availability. One DB instance down, the other DB instance still can provide DB service.

Can maintain one DB server while the other is still work.

High scalability.  Can add or delete DB instance online.

Disadvantage of RAC:

If the disk array damage, DB service is not available.(舉例:如整個磁盤陣列損壞,或HBA卡損壞)

Db performance may not better or even worse then single DB instance;

Complex management.

Advantage of DG:

High availability. The primary DB and standby DB can switch any time for DB crash or maintaince.

The standby DB backup the primary DB anytime.

Distribute work load , statistic, analyzing and report job can be done in standby DB.

Easy management.

Disadvantage of DG:

No obviously  disadvantage.

Unable to improve performance

Even Standby DB can take over control from Primary DB automatic, However, Application still need to change connect IP and reload configuration. 

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 159,458评论 4 363
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 67,454评论 1 294
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 109,171评论 0 243
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 44,062评论 0 207
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 52,440评论 3 287
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 40,661评论 1 219
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 31,906评论 2 313
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 30,609评论 0 200
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 34,379评论 1 246
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 30,600评论 2 246
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 32,085评论 1 261
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 28,409评论 2 254
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 33,072评论 3 237
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 26,088评论 0 8
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 26,860评论 0 195
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 35,704评论 2 276
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 35,608评论 2 270

推荐阅读更多精彩内容