使用Active Dataguard Reader Farm实现读写分离

原文链接:

http://www.dbaleet.org/seperate_read_and_write_by_oracle_active_dataguard_reader_farm/

Oracle Database 作为通用关系型数据库,常常需要满足客户的各种不同的业务模式,最典型的如交易密集型系统,决策分析型系统等等。很多人都发现了这么一个规律:互联网公司例如Google,Facebook等很少甚至没有使用Oracle的数据库产品,于是乎得出一个结论:互联网公司的基因决定了MySQL之类的开源数据库最佳之选,而Oracle Database并不适用于互联网公司的业务场景,故选用Oracle的产品是不明智的。这句话乍看上去有一定的道理,Oracle Database本身过于庞大,对于要求业务逻辑要求灵活多变的互联网确实不是太搭噶。

互联网公司是很少使用Oracle Database,但这其中最重要的因素绝非是技术层面的。绝大多数互联网公司都会对Oracle那价格不菲的license退避三舍,况且前面已经有足够使用开源技术的范例可以参详,购买Oracle Database实属毫无必要。互联网公司的业务逻辑比较类似,大多数(不是所有)互联网公司都是内容提供商,绝大多数业务以读为主,所以系统设计最基本的一条就是实现读写分离。那么有没有一些互联网公司基于Oracle Database来实现读写分离呢?又是怎么实现的呢?

据我所致,国外很多内容提供商都是基于Oracle Database实现的读写分离。例如Netflix, Amazon, Pandora等。早期Oracle Database自身能实现读写分离的技术非常有限,能做到实时同步的更是屈指可数。因为早期的Dataguard无法在应用日志的时候同时打开,最常用的技术都是逻辑复制的技术,例如Streams,Logical Standby,goldengate等。逻辑型复制技术存在的一个最大的问题就是无法保障同步的实时性,即使是goldengate也只能提供准实时的数据同步。另外就是逻辑性复制受限于业务逻辑本身,如果存在大量大事务,则可能出现拥塞,对于读写密集型的业务而言这种方式基本不可取。而11g的新特性Active Dataguard则很好的解决了这个问题。

Active Datagurad, 简单的说也就是可以打开的Dataguard,可以在应用Primary传过来的日志的同时将数据库以read only的模式打开。那么也就意味着,有了Active Dataguard, Standby Database不仅仅只是DR了,而是可供实时查询的备库,可以做到将“闲置”资源充分利用起来。而Active Dataguard Reader Farm看似是一个新名词,其实就是多个Active Standby组成的一个Farm,供大量的实时查询来使用。

当然以上只是一张概念图,以下是Apple使用Active Dataguard Reader Farm的一张架构图:

简单地对以上架构图做一些阐述:

1. Primary Database通常还会连接另外一个最大可用性模式的的Standby Database作为DR,以同步的方式应用Primary的变更。一旦Primary Database发生故障就可以切换到Standby Database而不会丢失任何数据。

2. Active Dataguard Reader Farm一般采用异步实时的模式应用日志,防止对Primary Database造成负面影响。在11.2还可以通过Query SLA的来监控和控制。通过V$DATAGUARD_STATS和V$STANDBY_EVENT_HISTOGRAM来监控其延迟,以及通过session级别设置STANDBY_MAX_DATA_DELAY来控制其延迟的行为。

3. 在应用服务器层面进行负载均衡,将多个应用服务器发送过来的请求通过一个硬件的load balancer (例如BigIP F5或者Citrix  NetScaler ADC)均衡分布到Active Dataguard Reader Farm的各个节点。

4. 另外注意到有一个细节就是,在Standby Database上还可以级联一个或者多个Active Dataguard作为Reader Farm中的节点。这个主要因为在11.1中,1个Primary Database只能有9个Standby Database的限制导致的。在11.2中不存在这个限制。

这样,应用所有的查询操作就均衡的分布到Active Dataguard Reader Farm节点,但是如果是变更操作应该如何处理呢?通常有两种处理手段: 第一种手段就是在应用层面做严格的区分,使得连接到Active Dataguard Reader Farm节点都是查询操作,连接到Primary Database的都是DML操作,当然这只是一种比较理想的模式。另外一种方式是在应用层面不进行区分,应用不直接连接到Primary Database,而是通过建立从Active Dataguard Reader Farm节点到Primary Database的dblink来做DML。

而如果需要了解Active Dataguard Reader Farm节点本身的负载情况,可以收集statspack或者ASH报告进行分析。

综上,Active Dataguard Reader Farm架构至少存在以下优势:

1. 管理维护简单,DBA只要熟悉Dataguard的管理即可,无需再额外学习其他方面的新知识;

2. Active Dataguard Reader Farm节点是灵活可扩展的,可以在线添加或者删除节点,并且可以线性扩展而不对生产系统造成影响;

3. 可以真正做到实时查询,不会应为大事务造成同步阻塞,性能有保障;

4. 没有数据类型的限制;

5. 高可用性, 节点的宕机都不会影响到数据库的可用性。

但是同时也需要注意:

1. Active Dataguard是11g数据库单独的一个option,需要单独付费的。

2. 无法在Active Dataguard Reader Farm节点单独创建索引进行查询优化。

3. 在所有Active Dataguard Reader Farm节点上sql的执行计划最好保持一致。

以上仅仅只是对Active Dataguard和Active Dataguard Reader Farm做一个简单的介绍,不可能涵盖到所有的方面。稍后我会上传Active Dataguard Best Practices以及如何Active Dataguard 的Hands on Lab到评论中,请自行查阅。

Comment

*

沪ICP备14014813号

沪公网安备 31010802001379号