[WK-T]ORACLE 10G 配置故障轉移(Failover)
文章參考:《大話 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出現故障,客戶端的會話就會斷開,不會自動連線到其他正常節點,需要重啟會話建立連線
3)當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種型別:session 和select.
這兩種方式對於未提交的事務都會自動回滾,區別在於對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配置,如下
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種型別:session 和select.
這兩種方式對於未提交的事務都會自動回滾,區別在於對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是否建立成功
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語法如下:
批註:其中TAF-policy選項可以是BASIC或PRECONNECT
2)檢視配置
客戶端連線測試:
在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,在作業系統上殺掉這個程式。
當前會話查詢例項名和執行狀態,此時會話已斷開如下:
批註:按理說應該會跳轉到rac2節點上,肯定哪個地方配置錯了,稍後重新再看看。
上述方法沒奏效,我選擇關閉節點rac1的例項,驗證結果。
補充:相同環境進行測試failover
1.客戶端連線並查詢會話ID
2.透過session ID在伺服器端作業系統中刪除該會話連線
3.會話並沒有斷開,伺服器為其分配一個新的session ID
批註:當客戶端連線叢集資料庫時,由於某些原因session ID被異常終端,已經配置了伺服器端的故障轉移,該會話並不會終端,而是伺服器為其分配一個
新的session ID,繼續透過當前會話為使用者提供對資料庫的操作。如果當前會話連線的例項宕掉,會自動去尋找備用例項。
三.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 |
7)修改Service的TAF配置,需要使用dbms_service.modify_service
批註:無論使用DBCA還是srvctl命令來配置Service,都無法配置TAF的type、delay、retries這三個屬性。必須使用dbms_service包來修改這些屬性。
8)確認修改已經生效
方式二:使用命令配置Service
1)建立Service語法如下:
srvctl add service -d |
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/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- Oracle Dataguard故障轉移(failover)操作OracleAI
- Oracle RAC 客戶端故障轉移(failover) TAFOracle客戶端AI
- 各種主機部署故障轉移Failover的詳細配置AI
- ORACLE RAC TAF 配置(透明故障轉移)Oracle
- [WK-T]ORACLE 10G 配置負載均衡(LoadBalance)Oracle 10g負載
- 【ASK_ORACLE】手動配置DataGuard的自動化Client Failover(故障轉移)的serviceOracleclientAI
- 11g DataGuard實現故障轉移(Failover)AI
- Windows MPIO與EMC儲存的故障轉移模式(Failover Mode)Windows模式AI
- [WK-T]ORACLE 10G RAC+ASM增加controlfileOracle 10gASM
- keepalive配置mysql自動故障轉移MySql
- 配置 RAC 負載均衡與故障轉移負載
- Oracle Rman多通道故障轉移問題分析Oracle
- Oracle 10g RAC故障處理Oracle 10g
- 【轉載】Oracle 10g 配置isqlplusOracle 10gSQL
- 轉:Oracle RAC Failover 詳解OracleAI
- 搭建Windows故障轉移群集Windows
- Oracle RAC Failover 詳解[轉帖]OracleAI
- 理解透明應用程式故障轉移 (TAF) 和快速連線故障轉移 (FCF)
- 如何配置Oracle RAC Load Balance 及FailOverOracleAI
- Oracle 10g DataGuard物理主備切換-switchover與failoverOracle 10gAI
- oracle 10g rac 網路故障處理Oracle 10g
- [WK-T]ORACLE RAC +ASM Backup and Recovery(四)OracleASM
- [WK-T]ORACLE RAC +ASM Backup and Recovery(三)OracleASM
- Mysql MHA部署-05故障轉移MySql
- Oracle Data Guard快速啟動故障切換 - fast-start failover(FSFO)OracleASTAI
- [轉載]使用snmp 監控 Oracle 10g(10.2.0.4) --- 配置Oracle 10g
- 在 RHEL3 上配置 Oracle 10g Data Guard(轉)Oracle 10g
- ORACLE 10G rac故障處理一例Oracle 10g
- Oracle 10g 兩個監聽程式的故障Oracle 10g
- 配置Oracle 10g ASM磁碟Oracle 10gASM
- 5 切換和故障轉移操作
- Sentinel哨兵模式解決故障轉移模式
- redis健康檢查與故障轉移Redis
- ASA failover配置(A/S)AI
- [AlwaysOn] AlwaysOn可用性組的故障轉移和故障轉移模式[中英文對照] 3模式
- [AlwaysOn] AlwaysOn可用性組的故障轉移和故障轉移模式[中英文對照] 6模式
- [AlwaysOn] AlwaysOn可用性組的故障轉移和故障轉移模式[中英文對照] 5模式
- [AlwaysOn] AlwaysOn可用性組的故障轉移和故障轉移模式[中英文對照] 4模式