It should. In my case, CRS try to bring it up but cannot. (In other test case, CRS did not recognize failure at all - I had it few month ago). Installatipon problem bug in script, something else - I do not know. As I said, I do not see why I need VIP at all if it do not provide fast failover and failback.
It works in some cases (CRS migrate VIP forth and back). Troubles happen when it switch back to the original node - it cause 1 - 2 minutes service interruption because CRS migrate VIP back _BEFORE_ it starts all necessary services on the new node (so your applications lost connection and find impossible to reconnect for a few minutes - very good method to break many applications totally). I'd like to use Loadbalancer if I need really good failover, instead of relying to the badly designed VIP (and notice, that SqlPlus failover do not need VIP at all) - because LB do not switch working connections, and switch new connections ONLY after application starts on the new node.
If you think about it - Oracle RAC have a urgly mixture of 3 failover systems: - Oracle cleint failover and load balance - Oracle listener load balance (between all normal IP and all VIP IP, so I often have 4 sessions to node1, 4 to node2, 4 to node1 VIP and 4 to node2 VIP), - VIP failover
as a result, it became unpredictable. I prefer do not see VIP address at all, or have single, well designed VIP for the whole cluster.
-- -- Original Message -- -- From: "Silviu Marin-Caea" <silviu_marin-caea@(protected)> To: <suse-oracle@(protected)> Sent: Wednesday, February 08, 2006 1:46 AM Subject: Re: [suse-oracle] When should a VIP address move to other node?
> On Tuesday 07 February 2006 23:09, Alexei_Roudnev wrote: > > In my history, VIP address is very unreliable feature - it moves in 50 - > > 70% of all possible scenarios > > The question is not about reliability of VIP moving, but about behaviour. > > If one node is shutdown properly, the surviving node _should_ or _should not_ > get the VIP address of the halted node? > > In our case it doesn't happen but we're not sure if this is a malfunction or > normal behaviour. > > > -- > To unsubscribe, email: suse-oracle-unsubscribe@(protected) > For additional commands, email: suse-oracle-help@(protected) > Please see http://www.suse.com/oracle/ before posting > >
-- To unsubscribe, email: suse-oracle-unsubscribe@(protected) For additional commands, email: suse-oracle-help@(protected) Please see http://www.suse.com/oracle/ before posting
