RAC Failover的问题

coolingverse

当RAC其中一个几点宕掉了以后, 另一个节点出现

1. Fri Feb 24 19:38:56 2012
   
2. ospid 26163: network interface with IP address 192.168.1.1 is DOWN
   
3. Fri Feb 24 19:39:56 2012
   
4. ospid 26163: network interface with IP address 192.168.1.1 is now UP
   
5. Fri Feb 24 19:41:56 2012
   
6. ospid 26163: network interface with IP address 192.168.1.1 is DOWN
   
7. Fri Feb 24 20:25:58 2012
   
8. ospid 26163: network interface with IP address 192.168.1.1 is now UP

复制代码

查看crs日志vip2已经正常的漂移到了rac1上了

1. 2012-02-24 19:28:15.326: [  CRSRES][796287] Attempting to start `ora.portal2.vip` on member `portal1`
   
2. 2012-02-24 19:28:22.173: [  CRSRES][796287] Start of `ora.portal2.vip` on member `portal1` succeeded.

复制代码

192.168.1.1是心跳线所用的IP, 并且不能自动的failover到正常的节点, 是不是心跳的网卡不断的重启引起的不可以正常的failover呢?

谢谢, 刘大给解释解释.

[ 本帖最后由 coolingverse 于 2012-4-17 22:19 编辑 ]

Maclean Liu(刘相兵

请给出 DB 版本 ，上传压缩后的alert.log 和 /var/log/messages     和dmesg的输出

coolingverse

数据库的版本是10.2.0.4.0
/var/log/messages     和dmesg的输出 这个没法获取到

Maclean Liu(刘相兵

Cluster communication is configured to use the following interface(s) for this instance
  192.168.1.2
Fri May 21 05:14:57 2010
cluster interconnect IPC version:Oracle UDP/IP (generic)


Instance recovery: lock domain invalid but no dead threads
Fri May 21 06:06:00 2010
ospid 28993: network interface with IP address 192.168.1.2 is DOWN
Fri May 21 06:20:00 2010
ospid 28993: network interface with IP address 192.168.1.2 is now UP
Fri May 21 06:38:01 2010
ospid 28993: network interface with IP address 192.168.1.2 is DOWN
Fri May 21 06:47:01 2010
ospid 28993: network interface with IP address 192.168.1.2 is now UP
Fri May 21 06:49:01 2010
ospid 28993: network interface with IP address 192.168.1.2 is DOWN
Fri May 21 06:50:01 2010
ospid 28993: network interface with IP address 192.168.1.2 is now UP



现象 节点2 频繁的重启  ， 节点1 因为节点2的重启 频繁的发生 reconfiguration


Thread 2 advanced to log sequence 1125 (thread recovery)
Fri Feb 24 19:38:56 2012
ospid 26163: network interface with IP address 192.168.1.1 is DOWN
Fri Feb 24 19:39:56 2012
ospid 26163: network interface with IP address 192.168.1.1 is now UP
Fri Feb 24 19:41:56 2012
ospid 26163: network interface with IP address 192.168.1.1 is DOWN
Fri Feb 24 20:25:58 2012
ospid 26163: network interface with IP address 192.168.1.1 is now UP
Fri Feb 24 20:32:52 2012
Reconfiguration started (old inc 30, new inc 32)
List of nodes:
0 1
Global Resource Directory frozen
Communication channels reestablished
Master broadcasted resource hash value bitmaps
Non-local Process blocks cleaned out
Fri Feb 24 20:32:53 2012
LMS 0: 0 GCS shadows cancelled, 0 closed
Fri Feb 24 20:32:53 2012
LMS 3: 0 GCS shadows cancelled, 0 closed
Fri Feb 24 20:32:53 2012
LMS 2: 0 GCS shadows cancelled, 0 closed
Fri Feb 24 20:32:53 2012
LMS 1: 0 GCS shadows cancelled, 0 closed
Set master node info
Submitted all remote-enqueue requests
Dwn-cvts replayed, VALBLKs dubious
All grantable enqueues granted
Fri Feb 24 20:32:53 2012
LMS 3: 7721 GCS shadows traversed, 4001 replayed


Reconfiguration started (old inc 4, new inc 6)
List of nodes:
0
Global Resource Directory frozen
* dead instance detected - domain 0 invalid = TRUE
Communication channels reestablished
Master broadcasted resource hash value bitmaps
Non-local Process blocks cleaned out
Fri May 21 02:12:44 2010
LMS 0: 0 GCS shadows cancelled, 0 closed
Fri May 21 02:12:44 2010
LMS 1: 0 GCS shadows cancelled, 0 closed
Set master node info
Submitted all remote-enqueue requests
Dwn-cvts replayed, VALBLKs dubious
All grantable enqueues granted
Post SMON to start 1st pass IR
Fri May 21 02:12:44 2010
Instance recovery: looking for dead threads
Instance recovery: lock domain invalid but no dead threads
Fri May 21 02:12:44 2010
LMS 1: 26096 GCS shadows traversed, 0 replayed
Fri May 21 02:12:44 2010
LMS 0: 28558 GCS shadows traversed, 0 replayed
Fri May 21 02:12:44 2010
Submitted all GCS remote-cache requests
Fix write in gcs resources
Reconfiguration complete
Fri May 21 02:19:14 2010





伴随有  ospid 4968: network interface with IP address 192.168.1.1 is now UP  的警告

这可能是由于 192.168.1.1 相关的network interface 不可用导致的  node eviction reboot

建议你 检查 linux 下的dmesg 和 /var/log/messages 确认2个节点的 private network 始终可用。