Oracle高可用架构分析和总结.docxVIP

Oracle 高可用架构 Oracle 高可用架构是我所讲课程里的一个热门话题.本文尝试对此话题做一个总体的说明,内容涵盖”普通的”单实例数据库,DataGuard,RAC 以及扩展 RAC(有时也被称为”伸展集群”).Rac 与 Dataguard 组合在一起就是 Oracle 公司推广的最大可用性架构(Maximum Availability Architecture, MAA).除这些Oracle 的 HA 解决方案外,我还会简单介绍一个第三方的 HA 解决方案(远程镜 像,Remote Mirroring).我不准备深入介绍所有这些解决方案的细节,而只是想做出一点区分的工作,并简要介绍它们各自的优势以及可能的缺陷. 首先,我们将考察目前为止仍然是应用最为广泛的 Oracle 数据库架构:单实例数据库.一个 Oracle 数据库总是由一个数据库(由数据文件,在线重做日志控制文件组成)与一个实例(有内存结构,比如数据库高速缓冲区;以及后台进程,例如数据库写进程)组成.如果我们有一个数据库以及多个访问这个数据库的实例,这就是一个 RAC.如果只有一个实例访问这个数据库,就是单实例数据库.下图是一个所有组件都存储在一个服务器上的简单安装版本: 将数据库文件放置在 SAN(存储区域网络)的配置也是目前比较常见的配置,如下图所示: 从高可用的角度来看,这个架构是非常脆弱的:服务器A 与服务器B 都是单点故障, 数据库A 与数据库B 也都是单点故障.从而这些服务器所在的站点也是单点故障. 这样,只要其中一个单点发生故障,整个数据库将不可用.一个”普通的”RAC 就是为了解决其中的服务器单点故障的,如下图所示: 如果两个服务器的其中一个发生故障,数据库 C 将仍然可用.当然,使用 RAC 并不仅仅是为了实现 HA.在使用 RAC 的其它的理由中,一个比较可靠的理由是为了实现伸缩性(Scalability):如果应用需求在将来出现增长,我们可以通过添加新的节点(Node)到集群中来解决.另外,通过使用 RAC 我们还可以选择使用服务管理(Service-Management)与负载均衡(Load Balance).简言之,RAC 不仅仅是 HA,在此详述其它原因已经超出本文的范畴了.从HA 的视角看,使用RAC 的缺陷是:数据库C 以及相应的站点C 是单点.如果站点C 发生故障(比如火灾),数据库C 将不可用.因此,将数据库伸展到两个站点就成为我们的选择了,这也是通常所说的扩展RAC. 现在,这两个站点就不再是单点了.数据库 D 是在两个站点之间做镜像的.这个架构的缺陷是两个站点之间的网络连接的成本,如果两个站点之间的距离比较远的话.这很关键,因为需要镜像的数据量会非常大.实际上,这使得两个站点之间的距离局限于几公里以内,而这与想要实现的灾难保护目标之间有冲突.这 时,Dataguard 就隆重登场了:利用 DataGuard,我们很容易就可以实现长距离的灾难保护,因为,此时我们不再需要传输所有的数据量,而仅仅需要传输(相对小) 的重做日志.在下图中,每个服务器都像上面的服务器 A 与服务器 B 一样,只有一个实例: 备用数据库由来自主数据库的重做日志. 当主库发生故障时,我们可以失败切换 (Failover)到备库上并继续有效工作.这个失败切换工作可以由一个Observer(观察员程序,通常称为快速启动失败切换,Fast-Start Failover)自动实现.两个站点之间的距离达到几千公里(依赖于重做日志的传输策略与保护级别(protection level)).如果我们将 RAC 与 Dataguard 集合起来,我们就实现了MAA.显然,MAA 是一个昂贵的解决方案,不过它也同时享有RAC 与Dataguard 的所 有好处. 远程镜像是一个广受欢迎的第三方 HA 解决方案.总体上,它的架构与下图类似: 这时,也没有哪个站点是单点的,类似于使用扩展 RAC 架构.这个解决方案的缺陷是:站点间的距离也是严格受限制的,理由与扩展 RAC 架构类似.同时,在镜像进行的时候,第二个站点是无法提供服务的,这一点与上述的Oracle 提供的HA 解决方案不同.使用 RAC 时,所有的服务器与相应的站点都可以提供服务.哪怕是使用Dataguard,备用数据库也不仅仅是等待主库发生故障.除此之外,它还可以提供只读访问服务,这将可以有效降低主库的负载. 上图展示了Oracle 11g 的新特性”物理备用数据库上的实时查询”.在恢复过程中时,备用数据库也在同时提供只读访问.另外,还可以在物理备库(Physical Standby)上做离线备份(OffLoad Backup).