Oracle 学习之RAC(一) 架构解析

最新推荐文章于 2023-06-15 10:31:51 发布

weixin_34009794

最新推荐文章于 2023-06-15 10:31:51 发布

阅读量263

点赞数

文章标签：数据库运维操作系统

原文链接：http://blog.51cto.com/lqding/1683810

版权

Oracle Real Application Cluster 简称RAC，也就是我们常说的Oracle数据库集群。它一般有两台或者两台以上同构计算机及共享存储设备构成，可提供强大的数据库处理能力。下图简单的描述了单实例数据库和RAC之间的区别。

RAC与单实例最大的区别是，多个实例管理一个数据库。这个数据库必须安装在共享存储上。这样的架构有如下优点：

高可用其中某个或者某些实例宕机，并不影响该系统对外提供服务。
高性能集群的事务处理功能大大增强，多个实例可以并发的工作。
可扩展当系统性能遇到瓶颈时，通过增加节点可以提高数据库的性能。

RAC作为一个整体对外提供服务，对于用户来说，可以把整个集群看成一个虚拟的机器。rac架构图如下

对于RAC来说，要由3个网络组成。

存储网络：节点与存储之间的连接。
私有网络：节点之间数据交互，集群管理软件管理节点等。
公共网络：业务访问数据库时使用的网络。

关于IP：

11g RAC环境提供了4种IP。

1. 私有IP，私有网络通信时使用的IP地址。

2. 公有IP，通过业务网，用来管理实例时使用的网络。

3. 虚拟IP，也叫VIP，客户端连接实例使用的IP地址。之所以叫虚拟IP，这个ip并不是固定在某台服务器上不动的，而是当实例宕机后，会有集群管理软件将该IP转移到其他机器上。这样连接到此IP上的业务并不会中断。

4. SCAN ip，11g新引入的。对客户端提供统一的访问入口。客户端无需再知道到底有哪些vip。使用scanip的好处时，当集群节点增加或者减少时，无需调整客户端的连接参数。

RAC体系结构图

要把多台机器组织成一个集群，需要一个集群管理软件。集群管理软件用来管理各服务器资源，以及运行在集群件上的程序。集群件对于整个集群来说，相对于一个虚拟的操作系统。实例需要通过集群件与操作系统打交道。

RAC实例的后台进程

在上图中，RAC中的实例，除了有单实例固有的那些后台进程，还会多一些用来进行RAC实例之间进行交互的进程。这些进程的具体含义我们后面再详细介绍。

在RAC中，每个实例有自己单独的redo log和undo表空间。因为每个实例都要独自处理事务。但是这些redo和undo文件同样要放置在共享磁盘中，因为一旦实例崩溃，其他的实例要能读取到该实例的redo和undo进行事务的恢复。

RAC中引入了一个叫cache fusion的机制。也就是把所有机器的内存当成一个大的整体的内存来管理。

要管理这块内存，Oracle引入了GCS（Global Cache Service）、GES（Global Enqueue Service）、GRD（Global Resource Directory）这三个概念。

GRD：用来记录数据库cached block在各个instance上的分布情况，以及block的状态。

GRD分布在各个实例中，每个实例维护GRD的一部分。

GRD由GCS和GES共同管理，GCS管理buffer cache中的数据块缓存的一致性，GES管理数据块的锁信息。

既然每个实例只维护GRD的一部分，那么我要请求一个块时，是不是每个机器都要请求？显然不是这样的，因为这样效率会非常的低。那么GCS和GES会根据一定的算法，在RAC的各个节点中选择出一个节点作为Resource Master。这个Resource Master负责处理数据块的请求。并且Resource Master会在内存中记录每个instance中GRD的索引（个人的理解，不一定对，很多资料上的另一种理解为：GRD(Global Resource Directory) 可以看做是一个内部数据库，记录每个数据块在集群间的分布图，位于每个实例SGA中，每个实例SGA中的GRD汇成了一个完整的GRD。在RAC的master node上记录了该资源在所有节点上的使用信息，而每个节点的使用信息记录在本节点上。这样一来内存就保存了两份GRD、Master上一份，其他实例汇总也是一份，个人感觉这样的理解有点不靠谱）。

下面我们用一些场景来描述，Oracle是如何实现cache fusion中的数据一致性的。

一、无传输模式数据读。

1. 实例2通过GCS服务向Resource Master发送一个读共享请求。

2. Resource Master检索GRD，发现该块没有被缓存，通知实例2可以进行数据读取。

3. 实例2向磁盘发送一个数据块读请求。

4. 数据被读进buffer cache，并将数据块加上一个共享锁S，通过GCS通知Resource Master。

二、读到写操作的数据传输

1. 实例1向Resource Master发送一个数据块的‘独占’请求。

2. Resource Master 通过检索GRD，发现该块已经缓存在实例2中。然后将请求转到实例2上。

3. 实例2将该数据块的锁降级。并把数据块传输到实例1上。

4. 实例1将数据块加一个‘独占’锁，并把数据块状态报告给Resource Master。

三、写到写的数据传输

1. 实例4向Resource Master发送一个数据块的‘独占’请求。

2. Resource Master 通过检索GRD，发现该块已经缓存在实例1中。然后将请求转到实例1上。

3. 实例1将该数据块的锁降级。并把数据块传输到实例4上。

4. 实例4将数据块加一个‘独占’锁，并把数据块状态报告给Resource Master。

注：此时实例1上的事务有可能还没有提交，实例1将数据传输到实例2之前，一定要确保事务的redo写到磁盘上。实例1中缓存的块为实例4中缓存块前镜像PI（Past p_w_picpath）。如果此时Past p_w_picpath还没有写入到磁盘，那么这个块的写就不再由实例1负责。数据块的写入只能由当前块的主控者执行。并且如果实例4中的块没有被写入。实例1中的PI是不能废弃的。这样是为了实例的快速恢复。

四、写到读的数据传输