RAC与双机热备的区别

  • 格式:docx
  • 大小:18.67 KB
  • 文档页数:4

下载文档原格式

  / 4
  1. 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
  2. 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
  3. 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。

RAC与双机热备的区别。

在 Cluster ( 集群 ) 多机系统平台上,常用的高可用性技术有两种:双机热备份和 RAC 并行服务器。这两种方式采用的机制不同,实现的效果也不同。

1、双机热备份方式

在双机热备份方式下,数据库系统平时只能在一台服务器(例如服务器 A)上运行,另一台服务

器无法直接访问数据库,自然也无法进行负载分担。当服务器 A 由于故障失效时,由相应的操作

系统软件控制,将服务器 A 管理的存储设备 ( 如硬盘 ) 转交给服务器 B 控制,同时在服务器B 上

启动另一个数据库进程,管理数据库。这种切换并启动新的数据库核心的过程一般需要几十秒到

几分钟。

这种方式的主要缺点在于:

•由于需要重新启动数据库核心进程,无法保证数据库系统连续不间断地运行;

•在系统切换的过程中,客户端与服务器之间的数据库连接会中断,需要重新进行数据库的连接和登录工作;

•由于数据库系统只能在一台服务器上运行,另一台服务器无法分担系统的负载,实际上造成了客户投资的浪费。在有些系统中,为了解决双机负载分担的问题,将应用系统人为分

割为两个数据库系统,分别在两台服务器上运行。这种方式在一定程度上解决了负载分担

的问题,但给系统管理、统计分析等业务处理带来了很多额外的复杂性

2、RAC方式

在并行服务器方式下,两台 ( 或多台 ) 服务器上各自运行一个数据库核心进程,但共同管理、

操作一个数据库。客户端无论连接到哪个服务器都可以在数据库中进行操作。当服务器 A 由于故

障失效时,数据库系统本身并未停止工作,连接在服务器 B 上的客户端还可以继续进行正常工作。同时,服务器 B 上也不需要再启动新的数据库服务器进程,因此也没有“切换时间”。对于一些

特殊应用中严格要求前端应用不能中断的情况, Oracle 并行服务器还提供了一种“预连接 (pre-connect) ”方式,以这种方式连接的客户端当服务器端发生故障时,客户端与数据库服务器的连

接不会中断,会被 Oracle 并行服务器软件自动转接到还在正常工作的其它服务器上,不需要重新

输入用户名及口令。

同样有许多操作系统平台支持并行服务器方式的高可用性方案,例如 HP MC Service Guard OPS Edition 等。

与双机热备份方式相比, Oracle Real Application Cluster 并行服务器方式有以下优点:

•各服务器共享一个数据库,在正常运行时可以进行负载分担,无需考虑应用数据的人为分割

•并行服务器方式对应用完全透明,在应用程序设计和开发的过程中也不需要进行特殊编程,简化了开发的复杂程度,同时今后系统扩展也无需修改应用程序

•不需要重新启动数据库核心进程,缩短了故障造成的停机时间

3、RAC 的好处

具有 Cache Fusion 体系结构的 Oracle Real Application Clusters 为企业应用开发提供了以下好处:•应用系统灵活和毫不费力的伸缩性;应用用户可以登录到单独的虚拟高性能集群服务器。

向数据库添加节点非常容易,并且当需要添加处理器节点或者业务需求变化时,不用手工

对数据进行分区。对于所有的应用即时提供集群的可伸缩性--不用修改应用程序。

•较之传统集群数据库体系结构的高可用性解决方案;该体系结构为客户提供了几乎连续的数据访问,使硬件和软件故障导致的业务中断最小化。系统具备对多个节点失败的容错能力,使部件失败屏蔽开最终用户。

•单独的管理实体;为了进行所有管理操作,在集群中保持一个单独的系统映像。 DBA 一次性地进行安装、配置、备份、升级以及监控等功能,然后 Oracle 将管理功能自动分配到适宜的节点。这意味着 DBA 只管理着一个虚拟服务器。

•Cache Fusion 保存了所有 Oracle 客户在他们应用中学习和开发 Oracle 的投资。所有单节点数据库功能都保留下来,并且应用程序使用相同标准的 Oracle 接口连接到数据库上。

可伸缩性

基于 RAC 应用的用户或者中间层应用服务器客户,可以通过虚拟数据库服务名连接到数据库上。 Oracle 在集群中多个节点之间自动平衡用户负载。不同节点上的 Real Application Clusters 数据库实例预订所有数据库服务或者部分子集数据库服务。这使得 DBA 高度灵活地选定,连接到特定数据库服务的特定应用程序客户是否可以连接到某些或者全部的数据库节点。虽然每一个节点有一个不同的物理 IP 地址时,应用客户仍可以在一个逻辑数据库服务名的水平上进行连接。因此客户端对于不相关的事情如多服务器的多个地址可以毫不关心。随着业务的增长,应用系统可以从容地增加处理能力。 Cache Fusion 体系结构直接地利用新节点的 CPU 和内存资源。 DBA 无需用手工对数据重新分区。这个优点是这种体系结构的副产品,因为有透明度的数据存取是 Cache Fusion 的一项基本功能。 Cache Fusion 体系机构自动适应快速变化的应用需求及随之而来的工作负荷的改变。 DBA 也不必因为工作负荷变化而对数据进行手工的重新分区。 Real Application Clusters 通过动态地重新分配数据库资源,从而在节点之间用最小化的磁盘 I/O 和低的延迟通信来优化利用集群系统资源。这使得 Real Application Clusters 可以从容实现增加的应用吞吐量和优化的响应时间。

高可用性

Real Application Clusters 提供了真正的高可用性解决方案,关键的突破是在大多数数据库恢复期间能提供完整的数据库访问。这使得 Real Application Clusters 成为应用所要求的 24x7 可用性的最佳平台。

Real Application Clusters 在高可用性上在三个关键领域胜出:

•提供了数据库恢复期间的数据块访问

•透明的失效转移对最终用户屏蔽了系统失效

•N-1 节点失效的容错能力

只要有一个数据库节点幸存, Real Application Clusters 就能够提供完全的数据库访问和相对不间断的操作。

可管理性

Real Application Clusters 实现了真正意义上的一个单系统访问数据库,它提供了从任何节点到所有磁盘设备和远程高速缓存进行无缝数据访问的能力。此单系统映像延伸到所有数据库管理操作。安装、配置、备份、升级以及监控等操作只需进行一次,然后会自动发布到集群中所有节点上去。各种 Oracle 工具(如 Oracle Universal Installer 、 Database Configuration Assistant 以及Recovery Manager )将发现集群数据块中所有不同的节点并以它们为目标分配给想得到的任务。通过为特定的管理操作选择多个目标节点,管理任务在数据库集群中多个节点上执行。这为应用系统管理其环境带来了极大的可伸缩性上的经济实惠。例如,向数据库集群添加一个节点只会增加最小的管理任务。这样, Real Application Clusters 支持在线商务应用和决策支持之类的应用,并且为数据访问和管理提供了单一的虚拟高性能服务器。