Oracle 高可用架构

作者: Uwe Hesse
Oracle高可用架构是我所讲课程里的一个热门话题,本文尝试对此话题做一个总体的说明,内容涵盖”普通的”单实例数据库,DataGuard,RAC以及扩展RAC(有时也被称为”伸展集群”)。Rac与Dataguard组合在一起就是Oracle公司推广的最大可用性架构( Maximum Availability Architecture,MAA)。除这些Oracle的HA解决方案外,我还会简单介绍一个第三方的HA解决方案(远程镜像,Remote Mirroring)。我不准备深入介绍所有这些解决方案的细节,而只是想做出一点区分的工作,并简要介绍它们各自的优势以及可能的缺陷。

首先,我们将考察目前为止仍然是应用最为广泛的Oracle数据库架构:单实例数据库。一个Oracle数据库总是由一个数据库(由数据文件、在线重做日志控制文件组成)与一个实例(有内存结构,比如数据库高速缓冲区,以及后台进程,例如数据库写进程)组成。如果我们有一个数据库以及多个访问这个数据库的实例,这就是一个RAC。如果只有一个实例访问这个数据库,就是单实例数据库。下图是一个所有组件都存储在一个服务器上的简单安装版本:
singleinstance1.gif
将数据库文件放置在SAN(存储区域网络)的配置也是目前比较常见的配置,如下图所示:
singleinstance2.gif
从高可用的角度来看,这个架构是非常脆弱的:服务器A与服务器B都是单点故障,数据库A与数据库B也都是单点故障,从而这些服务器所在的站点也是单点故障。这样,只要其中一个单点发生故障,整个数据库将不可用。一个”普通的”RAC就是为了解决其中的服务器单点故障的,如下图所示:
rac.gif
如果两个服务器的其中一个发生故障,数据库C将仍然可用。当然,使用RAC并不仅仅是为了实现HA。在使用RAC的其它的理由中,一个比较可靠的理由是为了实现伸缩性(Scalability):如果应用需求在将来出现增长,我们可以通过添加新的节点(Node)到集群中来解决。另外,通过使用RAC我们还可以选择使用服务管理(Service-Management)与负载均衡(Load Balance)。简言之,RAC不仅仅是HA,在此详述其它原因已经超出本文的范畴了。从HA的视角看,使用RAC的缺陷是:数据库C以及相应的站点C是单点。如果站点C发生故障(比如火灾),数据库C将不可用。因此,将数据库伸展到两个站点就成为我们的选择了,这也是通常所说的扩展RAC。
extendedrac.gif
现在,这两个站点就不再是单点了。数据库D是在两个站点之间做镜像的。这个架构的缺陷是两个站点之间的网络连接的成本。如果两个站点之间的距离比较远的话,这很关键,因为需要镜像的数据量会非常大。实际上,这使得两个站点之间的距离局限于几公里以内,而这与想要实现的灾难保护目标之间有冲突。这时,Dataguard就隆重登场了:利用DataGuard,我们很容易就可以实现长距离的灾难保护,因为,此时我们不再需要传输所有的数据量,而仅仅需要传输(相对小)的重做日志。在下图中,每个服务器都像上面的服务器A与服务器B一样,只有一个实例:
dataguard1.gif
备用数据库由来自主数据库的 重做日志。 当主库发生故障时,我们可以失败切换( Failover)到备库上并继续有效工作。这个失败切换工作可以由一个Observer(观察员程序,通常称为快速启动失败切换, Fast-Start Failover)自动实现。两个站点之间的距离达到几千公里(依赖于重做日志的传输策略与保护级别( protection level))。如果我们将RAC与Dataguard集合起来,我们就实现了MAA。显然,MAA是一个昂贵的解决方案,不过它也同时享有RAC与Dataguard的所有好处。

远程镜像是一个广受欢迎的第三方HA解决方案,总体上,它的架构与下图类似:
remotemirroring.gif
这时,也没有哪个站点是单点的,类似于使用扩展RAC架构。这个 解决方案的缺陷是:站点间的距离也是严格受限制的,理由与扩展RAC架构类似。同时,在镜像进行的时候,第二个站点是无法提供服务的,这一点与上述的Oracle提供的HA解决方案不同。使用RAC时,所有的服务器与相应的站点都可以提供服务。哪怕是使用Dataguard,备用数据库也不仅仅是等待主库发生故障。除此之外,它还可以提供只读访问服务,这将可以有效降低主库的负载。
realtimequery.gif
上图展示了Oracle 11g的新特性”物理备用数据库上的实时查询”。在恢复过程中时,备用数据库也在同时提供只读访问。另外,还可以在物理备库( Physical Standby)上做离线备份(OffLoad Backup)。

附注:
其实还有另外一种可选择的架构, 基于Data Guard与单实例的一个结合。
类似于上面介绍的远程Data Guard方案,做了一点修正:将当前主库的一组Redo 日志放到远程(当然也受限于距离所产生的San 访问延时)。

来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/9399028/viewspace-682262/,如需转载,请注明出处,否则将追究法律责任。

转载于:http://blog.itpub.net/9399028/viewspace-682262/

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值