oracle HA 高可用性详解

标签: oracle ha 高可用性 | 发表时间:2014-06-03 07:56 | 作者:lovedieya
出处:http://blog.csdn.net

一、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测试;

首先用户用客户端服务进行连接:

[[email protected]]$ sqlplus scott/[email protected]

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的过程。

作者:lovedieya 发表于2014-6-2 23:56:57 原文链接
阅读:15 评论:0 查看评论

相关 [oracle ha 高可用性] 推荐:

oracle HA 高可用性详解

- - CSDN博客推荐文章
FAILOVER,Oracle RAC的高可用性的技术基础是Failover,就是指集群中的热河一个节点的故障都不会影响到用户的使用,连接到故障节点的用户会被自动转移到健康节点,从用户高手而言感觉不到这种切换,这个功能在Oracle中被称作Failover(故障转移). Oracle RAC的Failover可以细分为3中,分别是:.

MySQL HA 高可用性,MySQL Cluster 叢集

- - SSORC.tw
而 SQL Node (mysqld程序) 只是讓我們建立資料庫、表的地方 (看得到/var/lib/mysql/XXX),只是 SQL Node 這邊是看不到實際空間用量的. manager node 及所有的 node 都要裝 mysql-cluster (到 mysql 官網下載). manager node 設定,它只要 ndb_mgm 與 ndb_mgmd 而已.

HA-JDBC -

- -
The state manager component is responsible for storing the active status of each database in the cluster, as well as any durability state.

MySQL HA 的選擇…

- - Gea-Suan Lin's BLOG
Percona 把常見的 MySQL High Availability 選擇整理後發表成 Webinar,投影片在這裡可以看到 (以及下載):「 Choosing a MySQL High Availability Solution」. 沒有太多新的東西,主要還是再次描述 MySQL HA 這塊目前沒有萬靈丹,常見的這幾個方案各有自己的優缺點,會依照環境與需求而產生不同的選擇.

nginx + keepalive 实现HA

- - CSDN博客编程语言推荐文章
主nginx负载均衡器 192.168.166.203. 辅nginx负载均衡器 192.168.166.177. VIP地址 192.168.166.178. 二.修改配置文件为以下内容: [master slave].  state MASTER #(主机为MASTER,备用机为BACKUP).

SUSE Linux HA双机搭建

- - CSDN博客数据库推荐文章
原来的数据库服务器运行在HP DL388G7服务器上面,内存32G,由于业务增长,内存吃紧,加上时不时出现服务器硬件故障,由于是单实例单服务器,存在单点发现,于是打算采取一些措施改善一下:. 2)并搭建服务器操作系统级别的双机. 3)迁移数据库数据到新服务器. 前面已经写过数据迁移相关的文章,题目为“ EXP/IMP迁移数据”,链接如下: http://blog.csdn.net/laven54/article/details/8877940.

hdfs-ha热备原理

- - 开源软件 - ITeye博客
下面的总结来自于: http://dongxicheng.org/hadoop-hdfs/hdfs-ha-federation-deploy/ .            Hadoop 2.0中的HDFS增加了两个重大特性,HA和Federaion. HA即为High Availability,用于解决NameNode单点故障问题,该特性通过热备的方式为主NameNode提供一个备用者,一旦主NameNode出现故障,可以迅速切换至备NameNode,从而实现不间断对外提供服务.

MySQL HA Solution 2019(3)MyCat

- - 企业架构 - ITeye博客
0  . 0  .       .

MySQL HA Solution 2019(4)MaxScale

- - 企业架构 - ITeye博客
已有 0 人发表留言,猛击->> 这里<<-参与讨论. —软件人才免语言低担保 赴美带薪读研.

MySQL HA Solution 2019(2)ProxySQL

- - 企业架构 - ITeye博客
| hostgroup_id | hostname      | port | gtid_port | status | weight | compression | max_connections | max_replication_lag | use_ssl | max_latency_ms | comment |.