基于 RAC的数据库故障切换技术

□张 雷，苏冉冉，马 民，赵玉珍

(1．北京环球信息应用开发中心，北京 100094；2. 山西广播电视大学，山西 太原 030027)

Oracle数据库的高可用性是指Oralce数据库系统能够持续不间断的运行。造成Oracle数据库业务系统中断的原因主要有以下两种，第一种是由于Oracle数据库服务器硬件或软件系统的故障，致使Oracle应用服务器无法正常工作，从而导致业务中断；第二种是由于Oracle数据遭到破坏。如数据库故障或数据文件损坏，造成数据库无法正常工作，从而导致Oracle系统部分或全部中断。

第一种情况，通常只是指Oracle服务器硬件或是应用软件无法正常工作。在这种情况下如果能够将故障服务器所承担的功能转由其他正常服务器执行，就能够在最短时间内恢复业务系统的运行，发生这种情况，采用服务器硬件冗余方案是最有效的解决办法。

第二种情况，由于Oracle数据已经遭到破坏，即使服务器的硬件和操作系统都正常，仍可能造成数据库服务器无法正常工作，导致Oracle数据库服务器无法正常运行。如果发生这种情况有两种解决方法。一是将服务转由本地或异地其他存有业务数据副本的服务器接替运行。二是从备份，恢复系统中恢复历史备份的业务数据，从而恢复服务器的正常运行。

下面结合Oracle10g的特点，针对以上关键故障，给出利用RAC和数据备份对业务数据库进行容错设计的解决方法。

1. RAC简介

Oracle中的真正应用群集RAC (Real Application Cluster)是Oracle并行服务器OPS (Oracle Parallel Server)的最新版本，它要求由两台以上数据库服务器构成集群，通过网络连接，并且能够支持集群中所有计算机系统对一组共享磁盘系统的并发访问。

RAC的每个节点上都运行着一个Oracle实例，所有这些实例都通过共享磁盘系统访问同一数据库。数据库的重做日志文件和回滚段也位于这个共享磁盘系统上，服务器之间在保留原有IP的基础上，分别配置服务器的信任关系，用户在进行服务器连接时，并不需特意指定某个IP，只要连接虚拟IP，系统将根据服务器的是否可用及繁忙程度来自行决定连接其中一台。这样，集群服务器为客户提供单一系统映像SSI，即把客户的请求透明地定向到集群内部的各个服务节点，使用户看起来整个集群就是一台独立的高性能服务器。集群服务器中某个服务器由于故障或计划停机而无法使用时，集群中其它节点可以自动承担工作负载，对故障节点进行实例恢复，也就是说一个节点的故障不会影响集群中的其它节点，实现透明的故障切换。

RAC配置可以较好地满足业务管理子系统业务数据库的高可用设计目标，我们在设计中采用两台HPrx4640同构型服务器，共享一组磁盘阵列，配置成一组以主备方式工作的集群系统。

2. RAC配置

RAC是比较复杂的Oracle选件，在安装、配置和管理方面都较单机版本要复杂许多，只有通过合理设计并配置RAC，才能发挥透明故障切换的作用。

·网络配置

为使两台数据库服务器配置为RAC，每个节点必须至少拥有两块网卡：一块网卡用于公共网络上的客户程序通信，而另一块网卡用于专用服务器间通信。为了使用这种配置，首先必须在每个节点上配置hosts文件，使之对于公共节点和专用节点有唯一的名称，理论上使用针对公共网络和专门节点容易识别的主机名。尽管在一个拥有两节点的系统中可以将专用网络用一根交叉线进行连接，但考虑有些平台操作系统中的介质感应行为的存在不支持这种做法。例如，在Windows上，一个节点关机了，那么存活节点上用于互连的网卡会被禁用，因为互联网络上没有再感应的活动。这会导致存活节点出现错误。最好的解决方案是在节点之间使用一个专用的交换机，这意味着即使一个节点关机了，另一个节点上的网卡仍然存在(来自交换机的)持续活动。当然，这也可以用于多于两个节点的系统。

系统中，两台服务器之间不仅要实现快速故障切换，它们之间本身也会进行工作的协调与调度。因此，我们在两台服务器之间连接一条光纤，既心跳线，通过分别配置双机信任关系来实现服务器间的通信。通过心跳线，系统之间的调度能够更加快速地进行。两台服务器彼此通过专用网络虽然可以实现通信，但由于客户端对它的访问也是通过专用网络来进行，这时，如果客户正在连接服务器，而其中的一台已坏掉，正在通过专用网络来告知对方并同时进行故障切换，这时不论对于用户的访问还是系统之间的故障切换均会花去较多时间。使用光纤连接的心跳线，如果一台服务器发生故障，它会通过心跳线来告知对方，及时进行故障切换，对于用户来说，他并不关心它会连接到哪台服务器上工作，他在乎的就是速度，因此，进行故障切换并不会太多的影响客户端的访问，能极大地提高系统可用性。双机信任关系设置如下：

#vi /.rhosts

rx2620a root

rx2620a oracle

rx2620a-priv root

rx2620a-priv oracle

rx2620a-vip root

rx2620a-vip oracle

rx2620b root

rx2620b oracle

rx2620b-priv root

rx2620b-priv oracle

rx2620b-vip root

rx2620b-vip oracle

· 软件配置

为了在节点发生故障时能够更快地进行故障切换，我们使用虚拟IP地址。之所以选择虚拟IP原因是TCP超时。TCP超时对应用程序预期地可用性起了很大的影响。当RAC环境中的某个节点发生故障停止服务时，或者是任何有多个地址可以尝试的高可用环境发生故障时，客户端是没有办法知道的。如果客户端通过TNS别名来连接，或者是允许连接到多个节点的服务，客户端可能会不知情地将首次连接指向一个已经停止服务的节点。这对单个客户端本身来说没有什么问题，因为列表中是假设有多个地址的。同样，当客户端从列表中的第一个地址获得响应失败时，将会尝试下一个地址，直到连接建立成功。问题是它转到下一个地址的时间。客户会等待多长时间来决定它试图到达的主机是不可访问的？这个时间可能为几秒或几分钟等，在有些环境中这是不可接受的，如果一个节点停止服务几个小时，几天或者几周，数据库可那仍然运转正常，有很多个节点仍然可以访问数据库。但是，可能有一些客户端会忙于建立到已停机节点的初始连接，因此陷入无限期的等待，而在转向列表中下一个地址之前连接已经超时了。

遗憾的是，这个时间的设置已经超出了Oracle的控制范围了。另外，它还会随不同的客户端，不同的操作系统而变化。它由操作系统客户端的超时值来控制，因此对所有用户修改可能是很麻烦的，因为可能会需要很多的客户端和很多配置变更。改变超时的值甚至可能会给客户端正在运行的其他应用程序造成不良的后果，因为其他应用程序可能出于某种原因，需要一个较高的TCP超时值。

更糟糕的是，行为可能会不一致。如果打开了客户端故障转移，一些连接很可能在他们第一次尝试时就会成功，因为他们正好随机地连接到了一个可用的节点。但是，在其他的情况下，连接的次数会增加，因为客户端随机并无意识地挑选到了停止服务的节点作为首次尝试的节点。这在客户端看来结果是混乱并且失败的，尽管从数据库的角度来看，任何事情都应正常工作。

输入虚拟IP地址，通过使用虚拟IP地址，Oracle排除了TCP初始连接超时的问题，而不需要对单个的客户端做任何改变。这是通过强制客户连接首先进入到所有连接的虚拟IP地址来实现的。当所有的节点都正常工作时，每一个虚IP都运行在它指定的节点上，连接被定向到恰当的侦听器和服务。当发生意外时，有一个节点失效，CRS将踢开这个节点，并且这个节点的虚IP事实上将联机指向集群中另一个正常工作的节点，在那里虚拟IP仍然可以响应ping程序和连接尝试。更重要的是，要注意这个虚IP现在将不能接受到数据库的连接。但是，由于IP地址是可用的，它将能够立即响应连接尝试。给客户端的响应将正常地以ORA-12541的形式，说明没有可用的侦听器。这是因为该虚IP现在所在的节点有它自己的侦听器，但是它在侦听它自己的虚IP，而不是其他节点上的虚IP。客户端收到没有侦听器的消息后，它将能够立即使用ADDRESS_LIST中的下一个IP重试，而不用等待我们所想象的2分钟超时，因此，一个连接时故障切换仍然发生了，但是连接尝试在几秒钟之内就成功了。真正的ORA错误被掩盖了，所以客户端从来都没有发现这个错误。这样，每个节点上侦听器实际上侦听的是虚拟IP地址，客户程序连接也是针对虚拟IP进行的，一旦节点发生故障，虚拟IP地址将进行实际的故障切换，并在另一台节点上继续保持联机。

使用虚拟IP的目的并非是让客户程序能够使用其他节点上的虚IP继续与数据库保持连接。IP地址故障切换的目的是降低客户程序意识到某个节点发生故障所要花费的时间。如果IP进行故障切换并从其他节点上进行响应，那么正在与该虚IP连接的客户程序会立刻得到一个响应，只是响应的内容并不是连接成功，而是登录失败，这说明IP是活跃的，但该地址上没有可用的实例，这时，客户程序就能够立刻尝试地址列表上的其他地址再次进行连接，从而成功地与被赋予故障节点相同功能的可用节点的虚IP进行连接。在业务管理子系统中，我们使用如下方法配置虚拟IP：

#xhost +

#cd /home/oracle/app/oracle/product/10.2.0/crs_1/bin

#./vipca

执行./vipca运行图形界面，通过添加双机信任关系等来完成虚拟IP的配置。

在客户端使用RAC集群服务器需要完成对监听文件tnsnames.ora的配置，示例如下：

GRID =

(DESCRIPTION =

(ADDRESS = (PROTOCOL = TCP) (HOST = rmscvip1.us.oracle.com) (PORT=1521) )

(ADDRESS = (PROTOCOL = TCP) (HOST = rmscvip2.us.oracle.com) (PORT=1521) )

(LOAD_BALANCE = yes)

(CONNECT_DATA = (SERVICE_NAME = grid)

)

在该项中，地址将会被客户端随机尝试，因为设置了LOAD_BALANCE项。所以列表中的第一个地址并不总是首先被尝试的。客户端会随机地挑选一个地址来尝试，而不会考虑节点的可用性或者节点的负载量。选择时随机的，并且希望通过所有的客户端都随机挑选地址进行连接，使得结果负载的分布更平均一些。

另一方面，服务器端故障转移就更加职能化了。它由服务器参数文件中的REMOTE_LISTENER参数来控制。在每个服务器节点中，系统参数文件中的参数REMOTE_LISTENER应该指向一个TNSNAMES项，它反过来会列出集群中所有可用侦听器的IP和端口，如下所示：LISTENERS_GRID =

(ADDRESS_LIST =

(ADDRESS = (PROTOCOL = TCP) (HOST = rmscvip1.us.oracle.com) (PORT=1521) )

(ADDRESS = (PROTOCOL = TCP) (HOST = rmscvip2.us.oracle.com) (PORT=1521) )

)

系统参数文件中的REMOTE_LISTENER参数也设置为LISTENERS_GRID。*.remote_listener = 'LISTENERS_GRID'

同样，任何来到节点的连接都可能被侦听器重定向到其他的节点，而不需要客户端做任何特殊的配置。因为故障转移时在服务器上完成的，侦听器可以考虑单个节点的负载，并将新的连接定向到那些负载较轻的节点。客户端故障转移将不会与这个过程相冲突。如果REMOTE_LISTENER采用上面的定义，并和客户端故障转移结合在一起，客户端将首先随机地从客户端tnsnames.ora文件中挑选一个地址来连接。在做了这个选择之后，通信就通过服务器地址上的那个侦听器启动，侦听器然后就会检查负载并决定是接受连接还是将它重定向另外一个负载最轻的节点。

对于现代数据管理子系统，配制Oracle 10g RAC实现快速备份与恢复技术，保证在一个集群内单节点故障不影响集群内其它节点的运行，将导致意外和计划停机时间的所有可能降到最低或完全消除。

参考文献：

[1]萧文龙，陈怡如.Oracle 10g 数据库入门与实践[M].北京：清华大学出版社，2006.

[2]林晓东，刘心松.高可用性系统结构的研究[J].计算机应用，1997,(7).

[3]Buyya R.郑纬民，石 威等译.高性能集群计算:结构与系统(第一卷)[M].北京：北京电子工业出版社，2001.