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

使用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，供大量的实时查询来使用。

<img class="alignnone size-full wp-image-480" title="dg reader farms" src="http://www.dbaleet.org/wp-content/uploads/2012/12/dg-reader-farms.png" alt="" width="668" height="471" />

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

<img class="alignnone size-full wp-image-481" title="apple active dg reader farm" src="http://www.dbaleet.org/wp-content/uploads/2012/12/apple-active-dg-reader-farm.png" alt="" width="684" height="477" />

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

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到评论中，请自行查阅。

No related posts.