RAC的高可用也不是那么好用

oracle一直在“鼓吹”着他的rac是如何如何的高可用,如何如何的可以实现针对应用透明的failover,但是,在实际的使用过程中,要完全实现这样的透明,条件是何等的苛刻。

先从一次故障说起吧。某天中午正在吃饭的时候,突然接到电话做应用程序连接数据库挂死了,并且也在客户端测试连接数据库也是挂死,长时间没有响应。

该省的数据库是2节点的rac数据库,登录数据库后发现rac2已经宕机,只留着侦听还没宕。观察到rac2的alertlog为:

根据报错信息,看到是ora-29740的错误,这个一般是rac之间的通信问题,导致一个节点被踢出cluster group。具体的错误分析,还是要看trace文件:

在这里我们看到是由于ora-29740的reason 3引起宕机的,查询metalink(Note:219361.1)上得知:

OK,那么我们基本将问题定位在网络方面的原因,继续查看系统的syslog:

发现主机确实出现了网络问题,在rac2上连接不到rac1(10.203.17.1),此时应用挂死,怀疑是应用发起的连接去了rac2,而rac2的lsnr还是打开的但是instance已经宕机,由于配置了local lsnr和remote lsnr,在客户端也配置了load balance和failover,当应用的连接随机的连接到实例时候,由于配置了load balance和remote lsnr,需要检查对方节点的服务器负载,由于网络不正常,无法确定对方节点情况,因此挂死。关闭rac2上的lsnr后,应用恢复正常!!

从主机的syslog中进一步观察,主机的网络在12:18已经恢复,网络开始responding。ping rac1也是正常,检查cluster软件没有问题后,开始重启rac2的instance。

问题是,启动的时候再次出现了问题,本来rac1上的连接都是好的,且应用也是顺利的连接到rac1,可是在重启的时候,所有的应用挂死。由于考虑到此时两个节点是在做内存同步,对split brain的东西做回复。在这段时间内的rac2和rac1都会很慢,就让应用先等了一会……谁知过了15分钟了,rac2还是没起来,而且rac2 instance再次被lmon终止了。

汗!看来网络还是有问题!!白天不敢动了,怕再次影响业务,到晚上继续捣鼓……

晚上拉上了网络工程师,发现还是有“FJ_DB02 cmcld: GS connection to 10.203.17.1 not responding, closing”的报错,仔细的把网络检查了一遍:

发现在trace文件中:

发现此处配的10.203.17.2,即应用的连接的网段,没有用private网段,进一步检查:

发现也是没有配private的网卡。

由于这个省的rac的网络配置是这样的:
lan0 : 192.168.0.0
lan1 : 10.103.17.0
lan2 : 0.0.0.0
其中,lan2是lan1的备用。网卡lan1之间的连接是经过两台互为冗余的交换机,而lan0则是通过交叉线直接连接。应用程序通过10.103.17.0网段的IP连接数据库,因此,而lan0对于数据库来讲目前是没有用上的。lan1上的问题导致了此次rac2的宕机。

通过网络工程师的进一步ping包,发现lan1的接口上有丢包的现象,由于是少量的不稳定的丢包,并不是网络全断,因此也没有切换到lan2上。因此造成因为丢包而split brain,从而rac2实例宕机。而进一步的咨询现场了解到,在当天中午的12点多确实有人拔动过lan1的网线。可能是拔动后没有插紧,造成了这次宕机。

解决方法:重新插拔lan1的网线,更换网线,更换网口后,节点间的通信回复正常。顺利的启动rac2.

后续改进:将直连的interconnect改为通过交换机连接(需千兆网络),配置cluster_interconnects=ip_private.

总结:rac其实要求还是挺严格的。首先,在硬件上,要求千兆private网络用于interconnect,如果有多块网卡且既能做为interconnect通信又能用于应用连接,需要配置cluster_interconnects进行指定。load balance其实在2处地方可以做load balance:一处是在服务器端,根据配置的remote lsnr和local lsnr来做负载均衡,即在客户端指定连接rac1也有可能在服务器端做再次调整连去rac2;另一处是在客户端,通过客户端的tnsnames来配置load balance,客户端根据tnsnames中的address list随机的连接服务器端。至于最终连接到哪个节点,要根据服务器端的lsnr再做调整(感觉这不是很好控制,如果同时配置了客户端的load balance和服务器端的load balance,基本不可预知在客户端发起的连接会去哪个节点。更何况,oracle美其名曰说是通过cpu的负载来实现load balance,至于其中如何的运算cpu的比例,还是一个黑盒子。)。至于failover这个功能,感觉只是和已经连接上rac的实例select有关,update、insert还是基本不能实现TAF,至于新发起的连接,和failover没啥关系了……

相关文章

5条评论

  1. 我也有以下的錯誤求救耶!!:
    Fri Jun 13 00:27:37 2008
    IPC Send timeout detected.Sender: ospid 5000
    Receiver: inst 1 binc 10682 ospid 4224
    Fri Jun 13 00:27:39 2008
    Errors in file d:\oracle\product\10.2.0\admin\etccms\bdump\etccms3_lms1_5000.trc:
    ORA-27508: 傳送訊息發生 IPC 錯誤
    ORA-27300: OS 系統相依作業:IPCSOCK_Send 失敗, 狀態: 10054
    ORA-27301: OS 失敗訊息: 遠端主機已強制關閉一個現存的連線。
    ORA-27302: 失敗發生於: send_3

    Fri Jun 13 00:27:39 2008
    IPC Send timeout to 0.2 inc 26 for msg type 38 from opid 8
    Fri Jun 13 00:27:39 2008
    Communications reconfiguration: instance_number 1
    Fri Jun 13 00:27:39 2008
    Trace dumping is performing id=[cdmp_20080613002739]
    Fri Jun 13 00:29:20 2008
    Waiting for clusterware split-brain resolution
    Fri Jun 13 00:39:20 2008
    Errors in file d:\oracle\product\10.2.0\admin\etccms\bdump\etccms3_lmon_5540.trc:
    ORA-29740: 由成員 2, 群組拷貝 28 收回

    Fri Jun 13 00:39:20 2008
    LMON: terminating instance due to error 29740
    Fri Jun 13 00:39:20 2008
    WARNING: inbound connection timed out (ORA-3136)
    Fri Jun 13 00:39:20 2008
    Errors in file d:\oracle\product\10.2.0\admin\etccms\bdump\etccms3_pmon_2072.trc:
    ORA-29740: 由成員 , 群組拷貝 收回

    Fri Jun 13 00:39:20 2008
    Errors in file d:\oracle\product\10.2.0\admin\etccms\bdump\etccms3_lmd0_5396.trc:
    ORA-29740: 由成員 , 群組拷貝 收回

    Fri Jun 13 00:39:20 2008
    Errors in file d:\oracle\product\10.2.0\admin\etccms\bdump\etccms3_lms1_5000.trc:
    ORA-29740: 由成員 , 群組拷貝 收回

    Fri Jun 13 00:39:20 2008
    WARNING: inbound connection timed out (ORA-3136)
    Fri Jun 13 00:39:20 2008
    WARNING: inbound connection timed out (ORA-3136)
    Fri Jun 13 00:39:20 2008
    WARNING: inbound connection timed out (ORA-3136)
    …….
    Errors in file d:\oracle\product\10.2.0\admin\etccms\bdump\etccms3_dbw0_5380.trc:
    ORA-29740: 由成員 , 群組拷貝 收回

    Fri Jun 13 00:39:20 2008
    WARNING: inbound connection timed out (ORA-3136)
    Fri Jun 13 00:39:21 2008
    Errors in file d:\oracle\product\10.2.0\admin\etccms\bdump\etccms3_lck0_4744.trc:
    ORA-29740: 由成員 , 群組拷貝 收回

    Fri Jun 13 00:39:21 2008
    WARNING: inbound connection timed out (ORA-3136)
    Fri Jun 13 00:39:21 2008
    WARNING: inbound connection timed out (ORA-3136)

    Fri Jun 13 00:39:28 2008
    Errors in file d:\oracle\product\10.2.0\admin\etccms\bdump\etccms3_reco_1028.trc:
    ORA-29740: 由成員 , 群組拷貝 收回

    Instance terminated by LMON, pid = 5540
    Fri Jun 13 02:20:46 2008
    Starting ORACLE instance (normal)
    LICENSE_MAX_SESSION = 0
    LICENSE_SESSIONS_WARNING = 0
    Interface type 1 private 192.168.1.0 configured from OCR for use as a cluster interconnect
    Interface type 1 public 10.81.4.0 configured from OCR for use as a public interface
    Picked latch-free SCN scheme 2
    Autotune of undo retention is turned on.
    LICENSE_MAX_USERS = 0
    SYS auditing is disabled
    ksdpec: called for event 13740 prior to event group initialization
    Starting up ORACLE RDBMS Version: 10.2.0.1.0.
    System parameters with non-default values:
    processes = 150


    DB 是重啟了, 且有時候甚至不會重啟..
    還連兩天呢…
    還沒能找到直接解決方案呢……著急!!

  2. 好东西。今天上午还在劝说用户采用交换机做内网而不是直连呢。呵呵。活生生的例子拿给他们看额……

发表评论

电子邮件地址不会被公开。 必填项已用*标注

此站点使用Akismet来减少垃圾评论。了解我们如何处理您的评论数据