瀏覽了一下Oracle官方的網頁以及非官方的ppt，簡單了解了一下Oracle提供的高可用方案。
1. RAC
RAC, Real Application Clusters
多個Oracle服務器組成一個共享的Cache，而這些Oracle服務器共享一個基於網絡的存儲。這個系統可以容忍單機/或是多機失敗。
不過系統內部的多個節點需要高速網絡互連，基本上也就是要全部東西放在在一個機房內，或者說一個數據中心內。如果機房出故障，比如網絡不通，那就壞了。所以僅僅用RAC還是滿足不了一般互聯網公司的重要業務的需要，重要業務需要多機房來容忍單個機房的事故。
2. Data Guard.
Data Guard這個方案就適合多機房的。某機房一個production的數據庫，另外其他機房部署standby的數據庫。Standby數據庫分物理的和邏輯的。物理的standby數據庫主要用於production失敗后做切換。而邏輯的standby數據庫則在平時可以分擔production數據庫的讀負載。
3. MAA
MAA(Maximum Availability Architecture)其實不是獨立的第三種，而是前面兩種的結合，來提供最高的可用性。每個機房內部署RAC集群，多個機房間用Data Guard同步。
Oracle+Fusionio+Dataguard的高可用方案
傳統的Oracle的高可用方案必須基於共享存儲設備，不管是雙機主備模式，還是Oracle RAC，數據庫必須放在共享的SAN存儲上，通過HA或集群軟件實現高可用。Oracle DataGuard是很好的容災軟件，但是作為HA解決方案，功能有很多局限性，比如數據丟失，應用透明切換，只能讀無法寫(11g)等等，目前都沒有非常好的解決方案。
自從固態存儲技術出現后，單機的IO能力大幅度提升，比如采用PCIE接口的fusionio卡，單塊卡就可以提供數萬IOPS的能力，單機的IO能力已經超過了傳統的磁盤存儲。但是，一直困擾我們的是，如何解決無共享存儲環境下Oracle數據庫的高可用問題？我們團隊設計了一種架構，提供簡單可靠的高可用功能。
雖然在Oracle的立場上，總是建議客戶能夠更好地規划自己的應用，在有其它負載平衡方法的時候，盡量不要依賴於Oracle的Load Balance方法，但是往往在給客戶配置完Oracle RAC數據庫以后，客戶都會要求要測試負載平衡（Load Balance）和TAF（Transparent Application Failover），並且將這兩個測試作為RAC是否安裝成功的標准。
這是一件很無奈的事情，像把旁枝末節看作了主要功能，甚至有些買櫝還珠的感覺，但是畢竟這是客戶，更了解Oracle Load Balance（后文用LB表示），才可以更好滿足客戶需求。
RAC的負載均衡主要是指新會話連接到RAC數據庫時，如何判定這個新的連接要連到哪個節點進行工作。在RAC中，負載均衡分為兩種，一種是基於客戶端連接的，另外一種是基於服務器端的。客戶端的負載均衡配置相對簡單，只需要在tnsnames.ora中添加LOAD_BALANCE=ON這么一個選項即可。
實現負載均衡(Load Balance)是Oracle RAC最重要的特性之一，主要是把負載平均分配到集群中的各個節點，以提高系統的整體吞吐能力。
通常情況下有兩種方式來實現負載均衡
一個是基於客戶端連接的負載均衡
客戶端的負載均衡主要是通過為tnsnames.ora增加load_balance=yes條目來實現
如果未開啟load_balance=yes時，Oracle Net會根據地址列表按順序來選擇一個進行連接，直到連接成功為止。 如果第一個host主機連接失敗，在有多個地址的情形下，接下來選擇第二個地址連接，依此類推，直到連接成功為止。當開啟了load_balance=yes時，則Oracle Net會從多個地址中隨機地選擇一個地址進行連接，直到連接成功為止。注意，此連接方式僅根據地址列表隨機選擇，並不考慮到各個實例上當前真正連接數量的多少，也即是沒有考慮各個節點真實的連接負載情況
二是基於服務器端監聽器(Listener)收集到的信息來將新的連接請求分配到連接數較少實例上的實現方式。
Oracle RAC服務器端的負載均衡是根據RAC中各節點的連接負荷數情況，將新的連接請求分配到負荷最小的節點上去。當數據庫處於運行時，RAC中各節點的PMON進程每3秒會將各自節點的連接負荷數更新到service_register。而對於節點中任意監聽器故障或監聽器意外失敗時，PMON進程會每1秒鍾檢查當前節點上的監聽是否重啟，以獲得最新的負載信息來及時調整負載均衡。
跨機房問題
跨機房問題一直都是一個老大難的問題，先看傳統數據庫的跨機房方案。
Master/Slave方案
這是最常用的方案，適用於大多數需求。Master將操作日志實時地發送到Slave，Slave當成Master的一個Hot Backup。Master宕機時，服務切換到Slave，需要修改客戶端邏輯使得Master失效時自動尋找新的Master。
這個方案有一個問題就是數據庫的Master和Slave一般不是強同步的，所以，切換到Slave后可能丟失宕機前的少量更新。如果將 Master和Slave做成強同步的，即：所有的數據必須同時寫成功Master和Slave才成功返回客戶端，這樣又帶來了另外一個問 題：Master和Slave中任何一台機器宕機都不允許寫服務，可用性太差。因此，Oracle有一種折衷的模式：正常情況下Master和Slave 是強同步的，當Master檢測到Slave故障，比如Slave宕機或者Master與Slave之間網絡不通時，Master本地寫成功就返回客戶 端。采用這種折衷的同步模式后，一般情況下Master和Slave之間是強同步的，Master宕機后切換到Slave是安全的。當然，為了確保數據安 全后，宕機的Master重啟后可以和新的Master(原有的Slave)對比最后更新的操作日志，如果發現不一致可以提醒DBA手工介入，執行數據訂 正過程。
Master和Slave之間強同步還有一個問題就是跨機房延時，對於關鍵業務，同城的機房可以部署專用光纖，在硬件層面上解決這個問題；異地的機房一般用來做備份，與主機房之間的數據同步一般是異步的，可能有秒級延時。
機房宕機切換自動化成本太高，但是對於很多單點服務，機房內部宕機切換的自動化很有必要。Oceanbase采用Linux的一個開源方 案：Pacemaker，通過heartbeat和虛IP漂移的方式實現機房內部宕機自動切換。由於主備切換本質上是一個選主問題，理論上只有Paxos 或者類似協議可以解決，而Pacemaker沒有采用復雜的Paxos協議，它對硬件是有依賴的，比如要求主備節點之間通過直連線保證網絡不會發生故障， 而這在機房內部是可以做到的。機房之間采用前面提到的Master/Slave方案，可以寫一個腳本ping主機房的Master，當確認主機房 Master宕機時(比如一分鍾不通)將服務切換到備機房並報警。