[WK-T]ORACLE 10G 配置故障轉移(Failover)

dayong2015發表於2014-08-25
文章參考:《大話 Oracle RAC 叢集 高可用性 備份與恢復》 張曉明 編著
Oracle  RAC 同時具備HA(High Availiablity) 和LB(LoadBalance). 而其高可用性的基礎就是Failover(故障轉移). 它指叢集中任何一個節點的故障都不會影響使用者的使用,連線到故障節點的使用者會被自動轉移到健康節點,從使用者感受而言, 是感覺不到這種切換。  

Oracle 10g RAC 的Failover 可以分為3種:
1. Client-Side Connect time Failover
2. TAF
3. Service-Side TAF
注意事項: 不能在listener.ora 檔案中設定GLOBAL_NAME, 因為這個引數會禁用Connect-time Failover 和 Transparent Application Failover.
一.Client-Side Connect Time Failover
Client-Side Connect Time Failover的含義:如果使用者端tnsname 中配置了多個地址,使用者發起連線請求時,會先嚐試連線地址表中的第一個地址,如果這個連線嘗試失敗,則繼續嘗試使用第二個地址,直至連線成功或者遍歷了所有的地址。
這種Failover的特點:只在建立連線那一時刻起作用,也就是說,這種Failover方式只在發起連線時才會去感知節點故障,如果節點沒有反應,則自動嘗試地址列表中的下一個地址。一旦連線建立之後,節點出現故障都不會做處理,從客戶端的表現就是會話斷開了,使用者程式必須重新建立連線。
啟用這種Failover的方法就是在客戶端的tnsnames.ora中新增FAILOVER=ON 條目,這個引數預設就是ON,所以即使不新增這個條目,客戶端也會獲得這種Failover能力。
示例:
在客戶端的tnsnames.ora 配置如下:

批註:SERVER = DEDICATED 表示專用伺服器模式設定,資料庫將為每一個客戶機連線分配專用資源。當預期客戶機連線總數較小,或客戶機向資料庫發出的請求持續時間較長,使用該模式;SERVER = SHARED 表示共享伺服器模式,多個客戶端連線共享一個資料庫分配的資源池,當大量使用者需要同時連線資料庫並且有效地利用系統資源時,使用此模式。
客戶端連線測試:
1)會優先從節點rac1連線資料庫

2)如果節點rac1出現故障,客戶端的會話就會斷開,不會自動連線到其他正常節點,需要重啟會話建立連線
[oracle@rac1 ~]$ srvctl status instance -d orcl -i orcl1
Instance orcl1 is running on node rac1
[oracle@rac1 ~]$ srvctl stop instance -d orcl -i orcl1
[oracle@rac1 ~]$ srvctl status instance -d orcl -i orcl1
Instance orcl1 is not running on node rac1

3)當rac1例項恢復正常之後,新的會話還會優先透過該節點連線資料庫
[oracle@rac1 ~]$ srvctl status instance -d orcl -i orcl1
Instance orcl1 is not running on node rac1
[oracle@rac1 ~]$ srvctl start instance -d orcl -i orcl1
[oracle@rac1 ~]$ srvctl status instance -d orcl -i orcl1
Instance orcl1 is running on node rac1

二. TAF(Transparent Application Failover)
客戶端連線故障切換最大的問題是,建立連線後如果節點發生故障,是不能做到故障轉移的,這樣資料庫的可用性就會大打折扣,所以oracle又提供了TAF的方法來解決連線時的故障切換,所謂TAF,就是連線建立以後,應用系統執行過程中,如果某個例項發生故障,連線到這個例項上的使用者會被自動遷移到其他的健康例項上。對於應用程式而言,這個遷移過程是透明的,不需要使用者的介入,當然,這種透明要是有引導的,因為使用者的未提交事務會回滾。 相對與Client-Side Connect Time Failover的使用者程式中斷,丟擲連線錯誤,使用者必須重啟應用程式,TAF 這種方式在提高HA上有了很大的進步。
TAF 的配置也很簡單,只需要在客戶端的tnsnames.ora中新增FAILOVER_MODE配置項。這個條目有4個子專案需要定義。
1. METHOD: 使用者定義何時建立到其例項的連線,有BASIC PRECONNECT 兩種可選值。 
    BASIC: 是指在感知到節點故障時才建立到其他例項的連線。
    PRECONNECT: 是在最初建立連線時就同時建立到所有例項的連線,當發生故障時,立刻就可以切換到其他鏈路上。
兩種方法比較: BASIC方式在Failover時會有時間延遲,PRECONNECT方式雖然沒有時間延遲,但是建立多個冗餘連線會消耗更多資源。
2. TYPE:用於定義發生故障時對完成的SQL 語句如何處理,其中有2種型別:sessionselect.
這兩種方式對於未提交的事務都會自動回滾,區別在於對select 語句的處理,對於select,使用者正在執行的select語句會被轉移到新的例項上,在新的節點上繼續返回後續結果集,而已經返回的記錄集則拋棄。
假設使用者正在節點1上執行查詢,整個結果集共有100條記錄,現在已從節點1上返回10條記錄,這時節點1當機,使用者連線被轉移到節點2上,如果是session模式,則需要重新執行查詢語句;如果是select方式,會從節點2上繼續返回剩下的90天記錄,而已經從節點1返回的10條記錄不會重複返回給使用者,對於使用者而言,感受不到這種切換。
顯然為了實現select 方式,Oracle 必須為每個session儲存更多的內容,包括遊標,使用者上下文等,需要更多的資源也是用資源換時間的方案。
3.DELAY和RETRIES 這兩個引數代表重試間隔時間和重試次數。
示例:
在客戶端的tnsnames.ora 配置如下:

客戶端連線測試:
1)因為節點rac1是正常的,所以會從該節點連線到資料庫

2)關閉節點rac1,當前會話會自動切換到正常節點連線資料庫

補充:檢視使用者連線的TAF配置,如下

批註:查詢結果中如果是NONE,說明這個連線沒有使用TAF;如果和客戶端tnsnames.ora配置中的相同,說明使用了TAF。
三.Service-Side TAF 
Service-Side TAF,伺服器透明故障轉移可以看作是TAF的一個變種。首先Service-Side TAF也是TAF,所有TAF的特點它都具有;其次,這種TAF是在伺服器
上配置的,而不像TAF在客戶端配置的。
Client-Side TAF 配置過程需要修改客戶端的tnsnames.ora檔案,如果有很多客戶端使用這個資料庫,那麼每次微小的引數調整都要把所有客戶端的
tnsnames.ora都調整一遍,既低效又易出錯。而Service-Side TAF透過結合Service,在資料庫裡儲存FAIL-MODE的配置,把所有的TAF配置儲存在資料字典
中,從而省去了客戶端的配置工作。
從配置引數而言,Service-Side TAF和TAF相比多了一個Instance Role 的概念。所謂例項Instance Role就是當多個Instance參與一個Service時,可以配置最佳化
使用哪一個Instance為使用者提供服務。使用者共享兩種可選角色。
PREFERRED:首選例項,會優先選擇擁有這個角色的例項提供服務。
AVAILABLE:後備例項,使用者連線會優先選擇PREFERRED的Instance,當PREFERRED的Instance不可用時,才會轉到AVAILABLE的Instance上
要使用Service-Side TAF必須配置Service。Service 可以在建立資料庫時建立,也可以在資料庫建立之後修改;既可以透過配置嚮導也可以透過命令方式進行
配置。
下面分別演示採用DBCA和手工兩種方式配置Service的過程。
方式一:使用DBCA配置Service
1)oracle使用者下執行DBCA出現歡迎介面

2)在已有的RAC資料庫上建立新的Service,此處選擇"Service Management"

3)選擇要配置Service的資料庫

4)新增Service名字以及定義例項角色

5)檢視配置的Service是否建立成功
[oracle@rac1 ~]$ crs_stat -t -v
Name           Type           R/RA   F/FT   Target    State     Host
----------------------------------------------------------------------
ora.HHPEN1.db  application    0/1    0/1    OFFLINE   OFFLINE
ora.orcl.db    application    0/1    0/1    ONLINE    ONLINE    rac2
ora....l1.inst application    0/5    0/0    ONLINE    ONLINE    rac1
ora....l2.inst application    0/5    0/0    ONLINE    ONLINE    rac2
ora...._TAF.cs application    0/0    0/1    ONLINE    ONLINE    rac1
ora....cl1.srv application    0/0    0/0    ONLINE    ONLINE    rac1
ora....SM1.asm application    0/5    0/0    ONLINE    ONLINE    rac1
ora....C1.lsnr application    0/5    0/0    ONLINE    ONLINE    rac1
ora.rac1.gsd   application    0/5    0/0    ONLINE    ONLINE    rac1
ora.rac1.ons   application    0/3    0/0    ONLINE    ONLINE    rac1
ora.rac1.vip   application    0/0    0/0    ONLINE    ONLINE    rac1
ora....SM2.asm application    0/5    0/0    ONLINE    ONLINE    rac2
ora....C2.lsnr application    0/5    0/0    ONLINE    ONLINE    rac2
ora.rac2.gsd   application    0/5    0/0    ONLINE    ONLINE    rac2
ora.rac2.ons   application    0/3    0/0    ONLINE    ONLINE    rac2
ora.rac2.vip   application    0/0    0/0    ONLINE    ONLINE    rac2
SQL> show parameter service;

NAME                                 TYPE     VALUE
------------------------------------ -------- ------------------------------
service_names                        string   orcl, orcl_TAF
6)如果客戶端想要透過service方式連線資料庫,需要在TNS條目中使用service_name方式引用資料庫。
7)修改Service的TAF配置,需要使用dbms_service.modify_service

批註:無論使用DBCA還是srvctl命令來配置Service,都無法配置TAF的type、delay、retries這三個屬性。必須使用dbms_service包來修改這些屬性。
8)確認修改已經生效

方式二:使用命令配置Service
1)建立Service語法如下:
srvctl add service -d -s -r "preferred-instance-list" -a "avaiable-instance-list" -p
批註:其中TAF-policy選項可以是BASIC或PRECONNECT
2)檢視配置
srvctl config service -d database-name [-s service-name] [-a]
客戶端連線測試:
在ORACLE 10G中配置了Service-Side TAF之後,客戶端甚至不需要tnsnames.ora檔案,而是使用ORACLE 10G提供的新連線方法Easy Connect Naming
Methods。為了展示這一特性,測試之前先把客戶端的tnsnames.ora檔案改名存放,以保證客戶端在沒有TNS的情況下進行這個測試。使用Easy Connect
Naming Methods時的連線串格式如下:

username/password@[//]host[:port][/service_name]
客戶端連線操作如下:

批註:該連線對應的server process的OS PID是14469,在作業系統上殺掉這個程式。
[oracle@rac1 ~]$ ps -ef|grep 14469
oracle   14469     1  0 19:47 ?        00:00:00 oracleorcl1 (LOCAL=NO)
oracle   18000 17607  0 19:50 pts/3    00:00:00 grep 14469
[oracle@rac1 ~]$ kill -9 14469
當前會話查詢例項名和執行狀態,此時會話已斷開如下:

批註:按理說應該會跳轉到rac2節點上,肯定哪個地方配置錯了,稍後重新再看看。
上述方法沒奏效,我選擇關閉節點rac1的例項,驗證結果。


補充:相同環境進行測試failover
1.客戶端連線並查詢會話ID

2.透過session ID在伺服器端作業系統中刪除該會話連線


3.會話並沒有斷開,伺服器為其分配一個新的session ID


批註:當客戶端連線叢集資料庫時,由於某些原因session ID被異常終端,已經配置了伺服器端的故障轉移,該會話並不會終端,而是伺服器為其分配一個
新的session ID,繼續透過當前會話為使用者提供對資料庫的操作。如果當前會話連線的例項宕掉,會自動去尋找備用例項。

來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/29634949/viewspace-1257168/,如需轉載,請註明出處,否則將追究法律責任。

相關文章