原文链接

[WK-T]ORACLE 10G 配置故障转移(Failover)​blog.itpub.net

文章参考：《大话 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种类型：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是否创建成功
[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_TAF6)如果客户端想要通过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，继续通过当前会话为用户提供对数据库的操作。如果当前会话连接的实例宕掉，会自动去寻找备用实例。