oracle的高可用與負載均衡

瀏覽了一下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宕機時(好比一分鐘不通)將服務切換到備機房並報警。