一、HA
FAILOVER,Oracle RAC的高可用性的技術基礎是Failover,就是指叢集中的熱河一個節點的故障都不會影響到使用者的使用,串連到故障節點的使用者會被自動轉移到健康節點,從使用者高手而言感覺不到這種切換,這個功能在Oracle中被稱作Failover(容錯移轉)。
Oracle RAC的Failover可以細分為3中,分別是:
(1) Client-Side Connect time Failover;
(2) TAF;
(3) Server-side TAF;
注意:
不要再listener.ora中設定GLOBAL_DB_NAME,因為這個參數會禁用Connect-time Failover和TransparentApplication Failover。
Client-Side Connect time Failover
Client-Side Connect timeFailover的含義是:如果用戶端tnsname中配置了多個地址,使用者發起請求時,會先嘗試串連地址表中的第一個地址,如果這個串連嘗試失敗,則會繼續嘗試使用第二個地址,直至串連成功或者遍曆了所有的地址。
這種Failover的特點從他的名稱中“connect time”就表達的很清楚了,只在建立串連的那一時刻起作用。也就是說這種Failover方式只在發起串連時採取感知節點故障,如果發現節點沒有響應,則自動嘗試地址清單的下一個地址。一旦串連建立以後,節點出現故障都不會做處理,從用戶端的表現來看就是斷開,使用者程式必須重建立立串連。
啟用這種Failover的方法就是在用戶端的tnsnames.ora中添加FAILOVER=ON條目,這個參數預設就是ON,所以即使不添加這個條目,用戶端也會獲得這種Failover能力。
TAF(Transparent Apllication Failover)
從上文對Client-Side Connecttime Failover特點的分析可以看出,這種failover的意義有限。下載大部分流行的應用系統(比如WebLogic,JBOSS)都是啟動時就建立若干到資料庫的長串連,在應用程式整個生命週期內重用這些串連。Client-Side Connect Time Failover的工作方式是它對應用程式的可用性沒有極大地協助。
從8.1.5版本Oracle引入了新的Failover機制TAF.所謂TAF,就是串連建立以後,應用程式運行過程中,如果某個執行個體發生故障,串連到這個執行個體上的使用者會被自動遷移到其他的健康執行個體上。對於應用程式而言,這個千億過程透明、不需要使用者的介入,當然這種透明也是有引號的,因為使用者的未提交事務會復原。相對於Client-Side Connect Time Failover的使用者程式被中斷、拋出串連錯誤、使用者必須中期應用程式,TAF這種方式在提高應用程式HA能力上無疑是前進了一大步。
TAF的配置也很簡單,只需要在用戶端的tnsnames.ora中添加FAILOVER_MODE配置項,這個條目有4個子項目需要定義。
FRAC =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = frac1-vip)(PORT = 1521))
(ADDRESS = (PROTOCOL = TCP)(HOST = frac2-vip)(PORT = 1521))
(LOAD_BALANCE=YES)
(
CONNECT_DATA=
(SERVER=DEDICATED)
(SERVICE_NAME=FRAC)
(
FAILOVER_MODE=
(TYPE=session)
(METHOD=basic)
(RETRIES=180)
(DELAY=5)
)
)
)
(1) METHOD選項用於定義何時建立到其他執行個體的串連,有BASIC和PERCONNECT兩個選項值。
a. BASIC是指在感知到節點故障時才建立到其他執行個體的串連。
b. PERCONNECT是在最初建立串連時就同時建立到所有執行個體的串連,當發生故障時,立刻就可以切換到其他鏈路上。
兩種方法的不同很容易比較。BASIC方式在Faiover時會有時間言辭,PERCONNECT方式雖然沒有時間言辭,但是再建立多個冗餘兩節會消耗更多的資源,兩者就是用時間換資源和資源換時間的區別。
(2) Type選項用於定於發生故障時對完成的SQL語句如何處理,其有兩種類型:session和select。
這兩種方式對於未提交的事務都自動復原。區別在於對於select語句的處理,對於select類型,使用者正在執行的select語句也會被轉移到新的實力上,在新節點上繼續返回後續結果集,而已經返回的記錄結果集拋棄。
假設使用者正在節點1上執行查詢,整個結果集共有100條記錄,現在一從節點1上返回10條記錄,這時節點1宕機,使用者串連被轉移到節點2上,如果是session方式則需要重新執行查詢語句;如果是select方式會從節點2上繼續返回剩下的90條記錄,二已經從節點1返回的10條記錄不會重複返回給使用者,對於使用者而言感覺不到這種切換。
很顯然為了實現select方式,oracle必須為每個session儲存更多的內容,包括遊標、使用者、上下文等,需要更多的資源也是用資源換時間的方案。
(3) DELAY和RETRIES這兩個參數和簡單,代表著重試時間間隔和重試次數。
Failover(TAF)的測試藉助於前面監聽和tnsnames的配置,而在11G R2沒有引入之前出現故障用的是直接用叢集的vip“漂”進行容錯移轉,而在11G R2以後,引入了一個新的ip,即SCAN(SingleClient Access Name)IP,Scan是一個網域名稱,可以解析1到3個scan ip,用戶端可以通過SCAN名解析來訪問資料庫,其好處就是添加和刪除節點時不需要再有額外的用戶端維護,大大減少了維護方面的繁瑣工作。
在叢集環境中,我們配置的用戶端是以scan ip的方式進行配置的。當我們某個使用者在外面串連進來的時候,叢集會自動的根據負載把該會話串連到一個特定的執行個體,如果該會話正在select一個表,還未完成,該執行個體宕機了,oracle會自動將故障節點的失誤切換到另一個執行個體中執行,這樣的切換對於使用者來說是透明的。使用者不會感覺到異常,所執行操作也將返回正常的結果,這個也是RAC叢集的高可用性所在。
以下是在session模式做的網路failover測試;
首先使用者用用戶端服務進行串連:
[oracle@frac1admin]$ sqlplus scott/oracle@frac
SQL*Plus: Release11.2.0.3.0 Production on Wed Apr 16 01:55:37 2014
Copyright (c) 1982,2011, Oracle. All rights reserved.
Connected to:
Oracle Database 11gEnterprise Edition Release 11.2.0.3.0 - 64bit Production
With thePartitioning, Real Application Clusters, Automatic Storage Management, OLAP,
Data Mining and RealApplication Testing options
SQL> showparameter instance_name
NAME TYPE VALUE
---------------------------------------------------------- ------------------------------
instance_name string FRAC2
SQL> create tablebig_a as select * from dba_objects;
SQL>insert intobig_a select * from big_a;
為了保證資料的充足性,多執行幾次上面insert語句,由於磁碟空間限制,我在此執行了4次,共1203888條記錄。
由以上資訊可知使用者串連到frac2執行個體,此時可以執行一些DML操作:
SQL> selectOBJECT_TYPE,count(*) from big_a group by object_type;
在查詢未完成之前,把frac2執行個體進行宕機,會返回如下錯誤:
SQL> shutdownabort;
ORACLE instance shutdown.
SQL> selectOBJECT_TYPE,count(*) from dba_objects group by object_type;
selectOBJECT_TYPE,count(*) from dba_objects group by object_type
*
ERROR at line 1:
ORA-25408: can notsafely replay call
再次查看的是時候發現已經把會話自動切換到frac1執行個體:
SQL> /
OBJECT_TYPE COUNT(*)
------------------------------------------------
EDITION 1
INDEX PARTITION 302
TABLESUBPARTITION 32
CONSUMER GROUP 25
SEQUENCE 229
TABLE 2936
INDEX 5266
SYNONYM 28152
VIEW 5186
FUNCTION 305
JAVA CLASS 23165
JAVA SOURCE 2
INDEXTYPE 9
CLUSTER 10
TYPE 2913
RESOURCE PLAN 10
JOB 14
EVALUATIONCONTEXT 15
45 rows selected.
SQL> showparameter instance_name;
NAME TYPE VALUE
---------------------------------------------------------------------------- ------
instance_name string FRAC1
SQL> !hostname
frac1
Server-Side TAF
第三種方式是Server-Side TAF,但從名字上就可以猜出這種方式和之前的TAF有一定的關係。事實上也是這樣,可以把Server-Side TAF看做是TAF的一個變種。首先Server-Side TAF也是TAF,所有TAF的特點他都具有;其次,這種TAF是在伺服器上配置,而不像TAF是在用戶端配置的。
前面介紹的Client-Side TAF,配置過程需要修改用戶端tnsnames.ora檔案,如果有很多用戶端使用這個資料庫,那麼每次微小的參數調整都要把書友電腦更改一遍,即低效又易出錯。而Server-Side TAF通過結合Service,在資料庫裡儲存FAIL_MODE的配置,把所有的TAF配置儲存在資料字典裡,從而省去了用戶端的配置工作,現在用戶端的TNS檔案就不需要任何TAF的配置選項。
從配置參數而言,Service-Side TAF相比多了一個Instance Role(實力角色)的概念。所謂實力角色,就是當有多個Instance參與一個Service時,可以配置有限使用哪一個Instance為使用者提供服務。使用者總共有兩種可選角色。
a. PREFERRED:首選執行個體,會優先選擇擁有這個角色的執行個體提供服務。
b. AVILABLE:後備執行個體,使用者會優先串連PREFERRD的Instance,當PREFERRED的Instance不可用時,才會被轉移到AVILABLE的執行個體上。
要想使用Server-Side TAF必須配置Server。Server可以在建立資料庫時建立,也可以在資料庫建立之後修改;既可以通過設定精靈也可以通過命令列方式配置。下面分別示範用DBCA和手工兩種方式配置Service的過程。