【Oracle 集群】ORACLE DATABASE 11G RAC 知识图文详细教程之集群概念介绍

ゝ一世哀愁。 2022-06-06 07:22 530阅读 0赞

## 集群概念介绍 ##

### 集群术语须知 ###

服务硬件：指提供计算服务的硬件，比如 PC 机、PC 服务器。

服务实体：服务实体通常指服务软体和服务硬体。

节点（node）：运行 Heartbeat 进程的一个独立主机称为节点，节点是 HA 的核心组成部分，每个节点上运行着操作系统和Heartbeat 软件服务。

资源（resource）：资源是一个节点可以控制的实体，当节点发生故障时，这些资源能够被其他节点接管。如： 磁盘分区、文件系统、IP 地址、应用程序服务、共享存储

事件（event）：事件也就是集群中可能发生的事情，例如节点系统故障、网络连通故障、网卡故障和应用程序故障等。这些事件都会导致节点的资源发生转移，HA 的测试也是基于这些事件进行的。

## 什么是集群 ##

集群（cluster）就是一组计算机，它们作为一个整体向用户提供一组网络资源，这些单个的计算机系统就是集群的节点（node）。集群提供了以下关键的特性。

(一) 可扩展性。集群的性能不限于单一的服务实体，新的服务实体可以动态的加入到集群，从而增强集群的性能。

(二) 高可用性。集群通过服务实体冗余使客户端免于轻易遭遇到“out of service”警告。当一台节点服务器发生故障的时候，这台服务器上所运行的应用程序将在另一节点服务器上被自动接管。消除单点故障对于增强数据可用性、可达性和可靠性是非常重要的。

(三) 负载均衡。负载均衡能把任务比较均匀的分布到集群环境下的计算和网络资源，以便提高数据吞吐量。

(四) 错误恢复。如果集群中的某一台服务器由于故障或者维护需要而无法使用，资源和应用程序将转移到可用的集群节点上。这种由于某个节点中的资源不能工作，另一个可用节点中的资源能够透明的接管并继续完成任务的过程叫做错误恢复。

分布式与集群的联系与区别如下：

(一) 分布式是指将不同的业务分布在不同的地方。

(二) 而集群指的是将几台服务器集中在一起，实现同一业务。

(三) 分布式的每一个节点，都可以做集群，而集群并不一定就是分布式的。而分布式，从狭义上理解，也与集群差不多，但是它的组织比较松散，不像集群，有一定组织性，一台服务器宕了，其他的服务器可以顶上来。分布式的每一个节点，都完成不同的业务，一个节点宕了，这个业务就不可访问了。

集群主要分成三大类：

HA：高可用集群（High Availability Cluster）。

LBC：负载均衡集群/负载均衡系统（Load Balance Cluster）

HPC：科学计算集群（High Performance Computing Cluster）/高性能计算（High Performance Computing）集群。

## 为什么搭建数据库集群 ##

随着经济的高速发展，企业规模的迅猛扩张，企业用户的数量、数据量的爆炸式增长，对数据库提出了严峻的考验。对于所有的数据库而言，除了记录正确的处理结果之外，还面临着以下几方面的挑战。

*  *l  如何提高处理速度，实现数据库的均衡负载。*
 *  *l  如何保证数据库的可用性、数据安全性、以及如何实现数据集群可扩性。*
 *  *l  怎么综合解决这些问题成为众多企业关注的焦点。*

在数据库上，组建集群也是同样的道理，主要有以下几个原因：

(一) 伴随着企业的成长，业务量提高，数据库的访问量和数据量快速增长，其处理能力和计算速度也相应增大，使得单一的设备根本无法承担。

(二) 在以上情况下，若扔掉现有设备，做大量的硬件升级，势必造成现有资源的浪费，而且下一次业务量提升时，又将面临再一次硬件升级的高额投入。于是，人们希望通过几个中小型服务器组建集群，实现数据库的负载均衡及持续扩展；在需要更高数据库处理速度时，只要简单的增加数据库服务器就可以得到扩展。

(三) 数据库作为信息系统的核心，起着非常重要的作用，单一设备根本无法保证系统的下持续运行，若发生系统故障，将严重影响系统的正常运行，甚至带来巨大的经济损失。于是，人们希望通过组建数据库集群，实现数据库的高可用，当某节点发生故障时，系统会自动检测并转移故障节点的应用，保证数据库的持续工作。

(四) 企业的数据库保存着企业的重要信息，一些核心数据甚至关系着企业的命脉，单一设备根本无法保证数据库的安全性，一旦发生丢失，很难再找回来。于是，人们希望通过组建数据库集群，实现数据集的冗余，通过备份数据来保证安全性。

## 数据库集群的分类 ##

数据库集群技术是将多台服务器联合起来组成集群来实现综合性能优于单个大型服务器的技术，这种技术不但能满足应用的需要，而且大幅度的节约了投资成本。数据库集群技术分属两类体系：基于数据库引擎的集群技术和基于数据库网关（中间件）的集群技术。在数据库集群产品方面，其中主要包括基于数据库引擎的集群技术的 Oracle RAC、Microsoft MSCS、IBM DB2UDB、Sybase ASE，以及基于数据库网关（中间件）的集群技术的 ICX-UDS 等产品。

一般来讲，数据库集群软件侧重的方向和试图解决的问题划分为三大类：

*  *l  负载均衡集群（Load Balance Cluster，LBC）侧重于数据库的横向扩展，提升数据库的性能。*
 *  *l  高可用性集群（High Availability Cluster，HAC）侧重保证数据库应用持续不断。大部分的数据库集群侧重与此。*
 *  *l  高安全性集群（High Security Cluster，HSC）侧重于容灾。*

只有 Oracle RAC 能实现以上三方面

## 可扩展的分布式数据库架构 ##

(一) Oracle RAC：

其架构的最大特点是共享存储架构（Shared-storage），整个 RAC 集群是建立在一个共享的存储设备之上的，节点之间采用高速网络互联。OracleRAC 提供了非常好的高可用特性，比如*负载均衡和应用透明切块（TAF）*，其最大的优势在于对*应用完全透明*，应用无需修改便可切换到RAC 集群。但是RAC 的可扩展能力有限，首先因为整个集群都依赖于底层的共享存储，所以共享存储的 *I/O 能力和可用性决定了整个集群的可以提供的能力*，对于 I/O 密集型的应用，这样的机制决定后续扩容只能是 Scale up（向上扩展）类型，对于硬件成本、开发人员的要求、维护成本都相对比较高。Oracle显然也意识到了这个问题，在 Oracle 的 MAA（Maximum Availability Architecture）架构中，采用 ASM 来整合多个存储设备的能力，使得 RAC 底层的共享存储设备具备线性扩展的能力，整个集群不再依赖于大型存储的处理能力和可用性。

RAC 的另外一个问题是，*随着节点数的不断增加，节点间通信的成本也会随之增加*，当到某个限度时，增加节点可能不会再带来性能上的提高，甚至可能造成性能下降。这个问题的主要原因是 Oracle RAC 对应用透明，应用可以连接集群中的任意节点进行处理，当不同节点上的应用争用资源时，RAC 节点间的通信开销会严重影响集群的处理能力。所以对于使用 ORACLE RAC 有以下两个建议：

*  *l  节点间通信使用高速互联网络；*
 *  *l  尽可能将不同的应用分布在不同的节点上。*

基于这个原因，Oracle RAC 通常在 DSS 环境（决策支持系统Decision Support System ，简称DSS)中可以做到很好的扩展性，因为 DSS 环境很容易将不同的任务分布在不同计算节点上，而对于 OLTP 应用（On-Line Transaction Processing[联机事务处理][Link 1]系统），Oracle RAC 更多情况下用来提高可用性，而不是为了提高扩展性。

(二) MySQL Cluster

MySQL cluster 和 Oracle RAC 完全不同，它采用 无共享架构Shared nothing（shared nothing architecture）。整个集群由*管理节点(ndb\_mgmd)，处理节点(mysqld)和存储节点(*ndbd)组 成，不存在一个共享的存储设备。MySQL cluster 主要利用了 NDB 存储引擎来实现，NDB 存储引擎是一个内存式存储引擎，要求数据必须全部加载到内存之中。数据被自动分布在集群中的不同存 储节点上，每个存储节点只保存完整数据的一个分片(fragment)。同时，用户可以设置同一份数据保存在多个不同的存储节点上，以保证单点故障不会造 成数据丢失。MySQL cluster 主要由 3 各部分组成：

*  *l  SQL 服务器节点*
 *  *l  NDB 数据存储节点*
 *  *l  监控和管理节点*

这样的分层也是与 MySQL 本身把 SQL 处理和存储分开的架构相关系的。MySQL cluster 的优点在于其是一个分布式的数据库集群，处理节点和存储节点都可以线性增加，整个集群没有单点故障，可用性和扩展性都可以做到很高，更适合 OLTP 应用。但是它的问题在于：

*  *l   NDB（“NDB” 是一种“内存中”的[存储引擎][Link 2]，它具有可用性高和[数据一致性][Link 3]好的特点。） 存储引擎必须要求数据全部加载到内存之中，限制比较大，但是目前 NDB 新版本对此做了改进，允许只在内存中加 载索引数据，数据可以保存在磁盘上。*
 *  *l  目前的 MySQL cluster 的性能还不理想，因为数据是按照主键 hash 分布到不同的存储节点上，如果应用不是通过主键去获取数据的话，必须在所有的存储节点上扫描， 返回结果到处理节点上去处理。而且，写操作需要同时写多份数据到不同的存储节点上，对节点间的网络要求很高。*

虽然 MySQL cluster 目前性能还不理想，但是 share nothing 的架构一定是未来的趋势，Oracle 接手 MySQL之后，也在大力发展 MySQL cluster，我对 MySQL cluster 的前景抱有很大的期待。

(三) 分布式数据库架构

MySQL 5 之后才有了数据表分区功能（Sharding）， Sharding 不是一个某个特定数据库软件附属的功能，而是在具体技术细节之上的抽象处理，是水平扩展(Scale Out，亦或横向扩展、向外扩展)的解决方案，其主要目的是为突破单节点数据库服务器的 I/O 能力限制，解决数据库扩展性问题。比如 Oracle 的 RAC 是采用共享存储机制，对于 I/O 密集型的应用，瓶颈很容易落在存储上，这样的机制决定后续扩容只能是 Scale Up（向上扩展） 类型，对于硬件成本、开发人员的要求、维护成本都相对比较高。Sharding 基本上是针对开源数据库的扩展性解决方案，很少有听说商业数据库进行 Sharding 的。目前业界的趋势基本上是拥抱 Scale Out，逐渐从 Scale Up 中解放出来。

Sharding 架构的优势在于，集群扩展能力很强，几乎可以做到线性扩展，而且整个集群的可用性也很高，部分节点故障，不会影响其他节点提供服务。Sharding 原理简单，容易实现，是一种非常好的解决数据库扩展性的方案。Sharding 并不是数据库扩展方案的银弹，也有其不适合的场景，比如处理事务型的应用它可能会造成应用架构复杂或者限制系统的功能，这也是它的缺陷所在。**读写分离是架构分布式系统的一个重要思想**。不少系统整体处理能力并不能同业务的增长保持同步，因此势必会带来瓶颈，单纯的升级硬件并不能一劳永逸。针对业务类型特点，需要从架构模式进行一系列的调整，比如业务模块的分割，数据库的拆分等等。集中式和分布式是两个对立的模式，不同行业的应用特点也决定了架构的思路。*如互联网行业中一些门户站点*，出于技术和成本等方面考虑，更多的采用开源的数据库产品(如* MYSQ*L)，由于大部分是典型的读多写少的请求，因此为 MYSQL 及其复制技术大行其道提供了条件。而相对一些传统密集交易型的行业，*比如电信业、金融业等*，考虑到单点处理能力和可靠性、稳定性等问题，可能更多的采用商用数据库，比如 *DB2、Oracle *等。就数据库层面来讲，大部分传统行业核心库采用集中式的架构思路，采用高配的小型机做主机载体，因为数据库本身和主机强大的处理能力，数据库端一般能支撑业务的运转，因此，Oracle 读写分离式的架构相对MYSQL 来讲，相对会少。读写分离架构利用了数据库的复制技术，将读和 写分布在不同的处理节点上，从而达到提高可用性和扩展性的目的。最通常的做法是利用 MySQL Replication 技术，Master DB 承担写操作，将数据变化复制到多台 Slave DB上，并承担读的操作。这种架构适合 read-intensive 类型的应用，通过增加 Slave DB 的数量，读的性能可以线性增长。为了避免 Master DB 的单点故障，集群一般都会采用两台 Master DB 做双机热备，所以整个集群的读和写的可用性都非常高。除了 MySQL，*Oracle 从 11g *开始提供 Active Standby 的功能，也*具备了实现读写分离架构的基础*。读写分离架构的缺陷在于，不管是 Master 还是 Slave，每个节点都必须保存完整的数据，如 果在数据量很大的情况下，集群的扩展能力还是受限于单个节点的存储能力，而且对于 Write-intensive 类型的应用，读写分离架构并不适合。

采用 Oracle 读写分离的思路，Writer DB 和 Reader DB 采用日志复制软件实现实时同步； Writer DB 负责交易相关的实时查询和事务处理，Reader DB 负责只读接入，处理一些非实时的交易明细,报表类的汇总查询等。同时，为了满足高可用性和扩展性等要求，对读写端适当做外延，比如 Writer DB 采用 HA 或者 RAC 的架构模式，目前，除了数据库厂商的 集群产品以外，解决数据库扩展能力的方法主要有两个：数据分片和读写分离。数据分片(Sharding)的原理就是将数据做水平切分，类似于 hash 分区 的原理，通过应用架构解决访问路由和Reader DB 可以采用多套，通过负载均衡或者业务分离的方式，有效分担读库的压力。

对于 Shared-nothing 的数据库架构模式，核心的一个问题就是读写库的实时同步；另外，虽然 Reader DB只负责业务查询，但并不代表数据库在功能上是只读的。只读是从应用角度出发，为了保证数据一致和冲突考虑，因为查询业务模块可能需要涉及一些中间处理，如果需要在数据库里面处理(取决与应用需求和设计)，所以Reader DB 在功能上仍然需要可写。下面谈一下数据同步的技术选型问题：

能实现数据实时同步的技术很多，基于 OS 层(例如 VERITAS VVR)，基于存储复制(中高端存储大多都支持)，基于应用分发或者基于数据库层的技术。因为数据同步可能并不是单一的 DB 整库同步，会涉及到业务数据选择以及多源整合等问题，因此 OS 复制和存储复制多数情况并不适合做读写分离的技术首选。基于日志的 Oracle 复制技术，Oracle 自身组件可以实现，同时也有成熟的商业软件。选商业的独立产品还是 Oracle 自身的组件功能，这取决于多方面的因素。比如团队的相应技术运维能力、项目投入成本、业务系统的负载程度等。

采用 Oracle 自身组件功能，无外乎 Logical Standby、Stream 以及 11g 的 Physical Standby(Active Data Guard)，对比来说，Stream 最灵活，但最不稳定，11g Physical Standby 支持恢复与只读并行，但由于并不是日志的逻辑应用机制，在读写分离的场景中最为局限。如果技术团队对相关技术掌握足够充分，而选型方案的处理能力又能支撑数据同步的要求，采用 Oracle 自身的组件完全可行。选择商业化的产品，更多出于稳定性、处理能力等考虑。市面上成熟的 Oracle 复制软件也无外乎几种，无论是老牌的 Shareplex，还是本土 DSG 公司的 RealSync 和九桥公司的 DDS，或是 Oracle 新贵 Goldengate，都是可供选择的目标。随着 GoldenGate 被 Oracle 收购和推广，个人认为 GoldenGate 在容灾、数据分发和同步方面将大行其道。当然，架构好一个可靠的分布式读写分离的系统，还需要应用上做大量设计，不在本文讨论范围内。

(四)  CAP 和 BASE 理论

分布式领域 CAP 理论：

*  *l  Consistency(一致性), 数据一致更新，所有数据变动都是同步的*
 *  *l  Availability(可用性), 好的响应性能*
 *  *l  Partition tolerance(分区容错性) 可靠性*

定理：任何分布式系统只可同时满足二点，没法三者兼顾。

忠告：架构师不要将精力浪费在如何设计能满足三者的完美分布式系统，而是应该进行取舍。

关系数据库的 ACID 模型拥有 高一致性 + 可用性 很难进行分区：

*  *l  Atomicity 原子性：一个事务中所有操作都必须全部完成，要么全部不完成。*
 *  *l  Consistency 一致性. 在事务开始或结束时，数据库应该在一致状态。*
 *  *l  Isolation 隔离层. 事务将假定只有它自己在操作数据库，彼此不知晓。*
 *  *l  Durability. 一旦事务完成，就不能返回。*

(五)  跨数据库事务

2PC (two-phase commit)， 2PC is the anti-scalability pattern (Pat Helland) 是反可伸缩模式的，也就是说传统关系型数据库要想实现一个分布式数据库集群非常困难，关系型数据库的扩展能力十分有限。而近年来不断发展壮大的 NoSQL（非关系型的数据库）运动，就是通过牺牲强一致性，采用 BASE 模型，用最终一致性的思想来设计分布式系统，从而使得系统可以达到很高的可用性和扩展性。那么，有没有可能实现一套分布式数据库集群，既保证可用性和一致性，又可以提供很好的扩展能力呢？

BASE 思想的主要实现有按功能划分数据库 sharding 碎片BASE 思想主要强调基本的可用性，如果你需要 High 可用性，也就是纯粹的高性能，那么就要以一致性或容错性为牺牲，BASE 思想的方案在性能上还是有潜力可挖的。

*  l  共同点：都是关系数据库 SQL 以外的可选方案，逻辑随着数据分布，任何模型都可以自己持久化，将数据处理和数据存储分离，将读和写分离，存储可以是异步或同步，取决于对一致性的要求程度。
 *  l  不同点：NOSQL 之类的 Key-Value 存储产品是和关系数据库头碰头的产品 BOX，可以适合非 Java 如 PHP RUBY等领域，是一种可以拿来就用的产品，而领域模型 + 分布式缓存 + 存储是一种复杂的架构解决方案，不是产品，但这种方式更灵活，更应该是架构师必须掌握的。

目前，已经有很多分布式数据库的产品，但是绝大部分是面向 DSS 类型的应用，因为相比较 OLTP 应用，DSS 应用更容易做到分布式扩展，比如基于 PostgreSQL 发展的 Greenplum，就很好的解决了可用性和扩展性的问题，并且提供了很强大的并行计算能力。对于 OLTP 应用，业务特点决定其要求：高可用性，一致性， 响应时间短，支持事务和 join 等等。数据库和 NoSQL当越来越多的 NoSQL 产品涌现出来，它们具备很多关系型数据库所不具备的特性，在可用性和扩展性方面都可以做到很好。

第一，NoSQL 的应用场景非常局限，某个类型的 NoSQL 仅仅针对特定类型的应用场景而设计。而关系型数据库则要通用的多，使用 NoSQL 必须搞清楚自己的应用场景是否适合。

第二，利用关系型数据库配合应用架构， 比如 Sharding 和读写分离技术，同样可以搭建出具备高可用和扩展性的分布式数据库集群。

第三，关系型数据库厂商依然很强大，全世界有大量的 用户，需求必然会推动新的产品问世。

第四，硬件的发展日新月异，比如闪存的技术的不断成熟，未来闪存可以作为磁盘与内存之间的 cache，或者完 全替代磁盘。而内存价格越来越低，容量越来越大，In-memory cache 或 database 的应用越来越广泛，可以给应用带来数量级的性能提升。数据库面临的 IO 问题将被极大改善。

## RAC概述 ##

共享存储文件系统（NFS），或甚至集群文件系统（如：OCFS2）主要被用于存储区域网络（所有节点直接访问共享文件系统上存储器），这就使得节点失效而不影响来自其他节点对文件系统的访问，通常，共享磁盘文件系统用于高可用集群。

Oracle RAC的核心是共享磁盘子系统，集群中所有节点必须能够访问所有数据、重做日志文件、控制文件和参数文件，数据磁盘必须是全局可用的，允许所有节点访问数据库，每个节点有它自己的重做日志和控制文件，但是其他节点必须能够访问它们以便在那个节点出现系统故障时能够恢复。

Oracle RAC 运行于集群之上，为 Oracle 数据库提供了最高级别的可用性、可伸缩性和低成本计算能力。如果集群内的一个节点发生故障，Oracle 将可以继续在其余的节点上运行。Oracle 的主要创新是一项称为高速缓存合并的技术。高速缓存合并使得集群中的节点可以通过高速集群互联高效地同步其内存高速缓存，从而最大限度地低降低磁盘 I/O。高速缓存最重要的优势在于它能够使集群中所有节点的磁盘共享对所有数据的访问。数据无需在节点间进行分区。Oracle 是唯一提供具备这一能力的开放系统数据库的厂商。其它声称可以运行在集群上的数据库软件需要对数据库数据进行分区，显得不切实际。企业网格是未来的数据中心，构建于由标准化商用组件构成的大型配置之上，其中包括：处理器、网络和存储器。Oracle RAC 的高速缓存合并技术提供了最高等级的可用性和可伸缩性。Oracle 数据库 10g 和 OracleRAC 10g 显著降低了运营成本，增强了灵活性，从而赋予了系统更卓越的适应性、前瞻性和灵活性。动态提供节点、存储器、CPU 和内存可以在实现所需服务级别的同时，通过提高的利用率不断降低成本。

## RAC 集成集群件管理 ##

Oracle RAC 10g 在 Oracle 数据库 10g 运行的所有平台上提供了一个完整集成的集群件管理解决方案。这一集群件功能包括*集群连接、消息处理服务和锁定、集群控制和恢复*，以及一个*工作负载管理*框架（将在下文探讨）。Oracle RAC 10g 的集成集群件管理具有以下优势：

(一) 成本低。Oracle 免费提供这一功能。

(二) 单一厂商支持。消除了相互推诿的问题。

(三) 安装、配置和持续维护更简单。Oracle RAC 10g 集群件使用标准 Oracle 数据库管理工具进行安装、配置和维护。这一过程无须其它的集成步骤。

(四) 所有平台，质量始终如一。与第三方产品相比，Oracle 对新软件版本进行了更严格的测试。

(五) 所有平台，功能始终如一。例如，一些第三方集群件产品限制了集群内可以支持的节点的数量。借助Oracle RAC 10g，所有平台可以支持多达 64 个节点。用户还可以在所有平台上获得一致的响应体验，从而有效解决了高可用性挑战，包括服务器节点故障、互连故障以及 I/O 隔离现象等。

(六) 支持高级功能。这包括集成监视和通知功能，从而在发生故障时，在数据库和应用层之间实现快速协调的恢复。

## RAC 的体系结构 ##

RAC 是 Oracle 数据库的一个群集解决方案，是有着两个或者两个以上的数据库节点协调运作能力的。如下图所示的 RAC 结构图：

![161650379078397.png][]

集群管理器（Cluster Manager）在集群系统中对其他各个模块进行整合，通过高速的内连接来提供群集节点之间的通信。各节点之间内连接使用心跳线互联，心跳线上的信息功能确定群集逻辑上的节点成员信息和节点更新情况，以及节点在某个时间点的运行状态，保证群集系统正常运行。通信层管理节点之间的通信。它的职责是配置，互联群集中节点信息，在群集管理器中使用由心跳机制产生的信息，由通信层负责传输，确保信息的正确到达。还有一些群集监视进程不断验证系统的不同领域运行状况。例如，心跳监测不断验证的心跳机制的运作是否良好。在一个应用环境当中，所有的服务器使用和管理同一个数据库，目的是*分散每一台服务器的工作量*。硬件上至少需要两台以上的服务器，而且还需要一个共享存储设备；同时还需要两类软件，一类是集群软件，另外一类就是 Oracle 数据库中的 RAC 组件。同时所有服务器上的 OS 都应该是同一类 OS，根据负载均衡的配置策略，当一个客户端发送请求到某一台服务的 listener 后，这台服务器根据负载均衡策略，会把请求发送给本机的 RAC组件处理，也可能会发送给另外一台服务器的 RAC 组件处理，处理完请求后，RAC 会通过群集软件来访问共享存储设备。逻辑结构上看，每一个参加群集的节点有一个独立的实例，这些实例访问同一个数据库。节点之间通过集群软件的通信层（Communication Layer）来进行通信。同时为了减少 I/O 的消耗，存在一个全局缓存服务，因此每一个数据库的实例，都保留了一份相同的数据库 cache。RAC 中的特点如下：

*  l   每一个节点的实例都有自己的 SGA；
 *  l   每一个节点的实例都有自己的后台进程
 *  l   每一个节点的实力都有自己的 redo logs
 *  l   每一个节点的实例都有自己的 undo 表空间
 *  l   所有节点都共享一份 datafiles 和 controlfiles

## RAC 的结构组成和机制 ##

在 Oracle9i 之前，RAC 称为 OPS（Oracle Parallel Server）。RAC 与 OPS 之间的一个较大区别是，RAC 采用了Cache Fusion（高缓存合并）技术，节点已经取出的数据块更新后没有写入磁盘前，可以被另外一个节点更新，然后以最后的版本写入磁盘。在 OPS 中，节点间的数据请求需要先将数据写入磁盘，然后发出请求的节点才可以读取该数据。使用 Cache Fusion 时，RAC 的各个节点间数据缓冲区通过高速、低延迟的内部网络进行数据块的传输。下图是一个典型的 RAC 对外服务的示意图，一个 Oracle RAC Cluster 包含了如下的部分

![161651005015495.png][]

1.  集群的节点（Cluster node）——2 个到 N 个节点或者主机运行 Oracle Database Server。
2.  私有网络（Network Interconnect）——RAC 之间需要一个高速互联的私有网络来处理通信和 Cache Fusion。
3.  共享存储（shared Storage）——RAC 需要共享存储设备让所有的节点都可以访问数据文件。
4.  对外服务的网络（Production Network）——RAC 对外服务的网络。客户端和应用都通过这个网络来访问。

## RAC 后台进程 ##

Oracle RAC 有一些自己独特的后台进程，在单一实例中不发挥配置作用。如下图所示，定义了一些 RAC 运行的后台进程。这些后台进程的功能描述如下。

![161651137665241.png][]

（1）LMS（Global cache service processes 全局缓存服务进程）进程主要用来管理集群内数据块的访问，并在不同实例的 Buffer Cache 中传输数据块镜像。直接从控制的实例的缓存复制数据块，然后发送一个副本到请求的实例上。并保证在所有实例的 Buffer Cache 中一个数据块的镜像只能出现一次。LMS 进程靠着在实例中传递消息来协调数据块的访问，当一个实例请求数据块时，该实例的 LMD 进程发出一个数据块资源的请求，该请求指向主数据块的实例的 LMD 进程，主实例的 LMD 进程和正在使用的实例的 LMD 进程释放该资源，这时拥有该资源的实例的 LMS 进程会创建一个数据块镜像的一致性读然后把该数据块传递到请求该资源的实例的BUFFER CACHE 中。LMS 进程保证了在每一时刻只能允许一个实例去更新数据块，并负责保持该数据块的镜像记录（包含更新数据块的状态 FLAG)。RAC 提供了 10 个 LMS 进程（0~9），该进程数量随着节点间的消息传递的数据的增加而增加。（2）LMON（Lock Monitor Process，锁监控进程）是全局队列服务监控器，各个实例的 LMON 进程会定期通信，以检查集群中各个节点的健康状况，当某个节点出现故障时，负责集群重构、GRD 恢复等操作，它提供的服务叫做 Cluster Group Service（CGS）。

LMON 主要借助两种心跳机制来完成健康检查。

(一) *节点间的网络心跳（Network Heartbeat）*：可以想象成节点间定时的发送 ping 包检测节点状态，如果能在规定时间内收到回应，就认为对方状态正常。

(二) *通过控制文件的磁盘心跳（controlfile heartbeat）*：每个节点的 CKPT 进程每隔 3 秒钟更新一次控制文件的数据块，这个数据块叫做 Checkpoint Progress Record，控制文件是共享的，所以实例间可以互相检查对方是否及时更新来判断。

(三) *LMD（the global enqueue service daemon，锁管理守护进程）*是一个后台进程，也被称为全局的队列服务守护进程，因为负责对资源的管理要求来控制访问块和全局队列。在每一个实例的内部，LMD 进程管理输入的远程资源请求（即来自集群中其他实例的锁请求）。此外，它还负责死锁检查和监控转换超时。

(四) *LCK（the lock process，锁进程）*管理非缓存融合，锁请求是本地的资源请求。LCK 进程管理共享资源的实例的资源请求和跨实例调用操作。在恢复过程中它建立一个无效锁元素的列表，并验证锁的元素。由于处理过程中的 LMS 锁管理的首要职能，只有一个单一的 LCK 进程存在每个实例中。

(五)* DIAG（the diagnosability daemon，诊断守护进程）*负责捕获 RAC 环境中进程失败的相关信息。并将跟踪信息写出用于失败分析，DIAG 产生的信息在与 Oracle Support 技术合作来寻找导致失败的原因方面是非常有用的。每个实例仅需要一个 DIAG 进程。

(六) *GSD（the global service daemon，全局服务进程）*与 RAC 的管理工具 dbca、srvctl、oem 进行交互，用来完成实例的启动关闭等管理事务。为了保证这些管理工具运行正常必须在所有的节点上先start gsd，并且一个 GSD 进程支持在一个节点的多个 rac.gsd 进程位![004F.png_rev_2.6.1][]![0052.png_rev_2.6.1][]![0041.png_rev_2.6.1][]![0043.png_rev_2.6.1][]![004C.png_rev_2.6.1][]![0045.png_rev_2.6.1][]![0048.png_rev_2.6.1][]![004F.png_rev_2.6.1][]![004D.png_rev_2.6.1][]![0045.png_rev_2.6.1][]![002F.png_rev_2.6.1][]![0062.png_rev_2.6.1][]![0069.png_rev_2.6.1][]![006E.png_rev_2.6.1][]目录下，其![006C.png_rev_2.6.1][]![006F.png_rev_2.6.1][]![0067.png_rev_2.6.1][]文件为 ORACLEHOME/bin目录下，其log文件为ORACLE\_HOME/srvm/log/gsdaemon.log。GCS 和 GES 两个进程负责通过全局资源目录（Global Resource Directory GRD）维护每个数据的文件和缓存块的状态信息。当某个实例访问数据并缓存了数据之后，集群中的其他实例也会获得一个对应的块镜像，这样其他实例在访问这些数据是就不需要再去读盘了，而是直接读取 SGA 中的缓存。GRD 存在于每个活动的 instance 的内存结构中，这个特点造成 RAC 环境的 SGA 相对于单实例数据库系统的 SGA 要大。其他的进程和内存结构都跟单实例数据库差别不大。

## RAC 共享存储 ##

RAC 需要有共享存储，独立于实例之外的信息，如上面提到的ocr 和 votedisk 以及数据文件都存放在这个共享存储里的。有OCFS、OCFS2、RAW、NFS、ASM 等这样的一些存储方式。OCFS（Oracle Cluster File System） 和 OCFS2 就是一个文件系统而已，和 NFS 一样，提供一种集群环境中的共享存储的文件系统。RAW 裸设备也是一种存储方式，是 oracle11g 之前的版本中 RAC 支持的存储方式，在 Oralce9i 之前，OPS/RAC的支持只能使用这样的方式，也就是把共享存储映射到 RAW Device，然后把 Oracle 需要的数据选择 RAW device存储，但是 RAW 相对于文件系统来说不直观，不便于管理，而且 RAW Device 有数量的限制，RAW 显然需要有新的方案来代替，这样就有了 OCFS 这样的文件系统。当然，这只是 Oracle 自己的实现的集文件系统而已，还有其他厂商提供的文件系统可以作为存储的选择方案。ASM 只是数据库存储的方案而已，并不是 cluster 的方案，所以这里 ASM 应该是区别于 RAW 和 OCFS/OCFS2同一级别的概念，RAW 和 OCFS/OCFS2 不仅可以作为数据库存储的方案，同时也可以作为 Clusterware 里的存储方案，是 CRS 里需要的 storage，而 ASM 仅作为数据库的存储而已，严格来说仅是 RAC 中的一个节点应用（nodeapps）。ASM 对于 clusterware 安装时需要的 ocr 和 votedisk 这两项还不支持，毕竟 ASM 本身就需要一个实例，而 CRS 是完全在架构之外的，这也就是为什么使用了 ASM 的方案，却总还要加上 OCFS/OCFS2 和 RAW 其中的一个原因。各种 RAC 共享存储方式的对比如下：

1.  集群文件系统——支持 windows 和 Linux 的 OCFS/OCFS2
2.  AIX 下的 GPFS 等方式——优点是管理方便，表示也很直观，但缺点是基于文件系统管理软件，又要经过 OS 的 cache 处理，性能上和稳定性上都有欠缺，所以不适合在生产环境下使用。可以支持 CRS 集群软件文件和数据库文件。
3.  RAW 裸设备方式——通过硬件支持的共享存储系统，直接用 RAW 设备存储，可以支持集群软件文件和数据库文件。
4.  网络文件系统（NFS）——通过 NFS 实现共享存储，不过需要经过 Oracle 认证的 NFS 才行，可以支持CRS 集群软件文件和数据库文件。
5.  ASM——集合 RAW 方式 I/O 高性能和集群文件系统易管理等优点，Oracle10g 下推出的共享存储方式，但是本身 ASM 就是需要 Oracle 的实例支持，所以 ASM 仅支持数据库文件，而不支持 CRS 文件。

## RAC 数据库和单实例数据库的区别 ##

为了让 RAC 中的所有实例能够访问数据库，所有的 datafiles、control files、PFILE/Spfile 和 redo log files 必须保存在共享磁盘上，并且要都能被所有节点同时访问，就涉及到裸设备和集群文件系统等。RAC database 在结构上与单实例的不同之处：至少为每个实例多配置一个 redo 线程，比如：两个实例组成的集群至少要 4 个 redo log group。每个实例两个 redo group。另外要为每一个实例准备一个 UNDO 表空间。

1、redo 和 undo，每个实例在做数据库的修改时谁用谁的 redo 和 undo 段，各自锁定自己修改的数据，把不同实例的操作相对的独立开就避免了数据不一致。后面就要考虑备份或者恢复时 redo log 和归档日志在这种情况下的特殊考虑了。

2、内存和进程各个节点的实例都有自己的内存结构和进程结构.各节点之间结构是基本相同的.通过 Cache Fusion（缓存融合）技术，RAC 在各个节点之间同步 SGA 中的缓存信息达到提高访问速度的效果也保证了一致性。

[Link 1]: http://baike.baidu.com/view/8028.htm
[Link 2]: http://baike.baidu.com/view/1238930.htm
[Link 3]: http://baike.baidu.com/view/4138648.htm
[161650379078397.png]: /images/20220606/654b292a20b24c3b920d5b136be35932.png
[161651005015495.png]: /images/20220606/c8e5b62069624124b97677eda4536932.png
[161651137665241.png]: /images/20220606/10f8d67924034284b19e956e5423aa8f.png
[004F.png_rev_2.6.1]: http://mathjax.cnblogs.com/2_6_1/fonts/HTML-CSS/TeX/png/Math/Italic/400/004F.png?rev=2.6.1
[0052.png_rev_2.6.1]: http://mathjax.cnblogs.com/2_6_1/fonts/HTML-CSS/TeX/png/Math/Italic/400/0052.png?rev=2.6.1
[0041.png_rev_2.6.1]: http://mathjax.cnblogs.com/2_6_1/fonts/HTML-CSS/TeX/png/Math/Italic/400/0041.png?rev=2.6.1
[0043.png_rev_2.6.1]: http://mathjax.cnblogs.com/2_6_1/fonts/HTML-CSS/TeX/png/Math/Italic/400/0043.png?rev=2.6.1
[004C.png_rev_2.6.1]: http://mathjax.cnblogs.com/2_6_1/fonts/HTML-CSS/TeX/png/Math/Italic/400/004C.png?rev=2.6.1
[0045.png_rev_2.6.1]: http://mathjax.cnblogs.com/2_6_1/fonts/HTML-CSS/TeX/png/Math/Italic/400/0045.png?rev=2.6.1
[0048.png_rev_2.6.1]: http://mathjax.cnblogs.com/2_6_1/fonts/HTML-CSS/TeX/png/Math/Italic/283/0048.png?rev=2.6.1
[004D.png_rev_2.6.1]: http://mathjax.cnblogs.com/2_6_1/fonts/HTML-CSS/TeX/png/Math/Italic/400/004D.png?rev=2.6.1
[002F.png_rev_2.6.1]: http://mathjax.cnblogs.com/2_6_1/fonts/HTML-CSS/TeX/png/Main/Regular/400/002F.png?rev=2.6.1
[0062.png_rev_2.6.1]: http://mathjax.cnblogs.com/2_6_1/fonts/HTML-CSS/TeX/png/Math/Italic/400/0062.png?rev=2.6.1
[0069.png_rev_2.6.1]: http://mathjax.cnblogs.com/2_6_1/fonts/HTML-CSS/TeX/png/Math/Italic/400/0069.png?rev=2.6.1
[006E.png_rev_2.6.1]: http://mathjax.cnblogs.com/2_6_1/fonts/HTML-CSS/TeX/png/Math/Italic/400/006E.png?rev=2.6.1
[006C.png_rev_2.6.1]: http://mathjax.cnblogs.com/2_6_1/fonts/HTML-CSS/TeX/png/Math/Italic/400/006C.png?rev=2.6.1
[006F.png_rev_2.6.1]: http://mathjax.cnblogs.com/2_6_1/fonts/HTML-CSS/TeX/png/Math/Italic/400/006F.png?rev=2.6.1
[0067.png_rev_2.6.1]: /images/20220606/803e605f66e44a2badf9d25d9dee1d3c.png