Home » Server Options » RAC & Failsafe » how to prevent VIP transfer back to it's original node location (11.2.0.3.0)
how to prevent VIP transfer back to it's original node location [message #570494] Sun, 11 November 2012 05:10 Go to next message
piotrtal
Messages: 168
Registered: June 2011
Location: Poland/Czestochowa
Senior Member
HI,

i wonder such scenario:

normally if node fails, VIP & resources are transfered to another node (clients need to failover).

if node is back again CRS detect this, make it as 'family member' and try transfer VIP & resources back to this node (clients will force to failover again).
this failover (despite of failover method I use) make each uncommited transaction to be rolled back. client need to be disconnected from the service and VIP throught they are connected to this service and they need reconnect to the new node - am i right?
during this stage all DMLs modifications are gone, and need to be reexecute.

I need to avoid such situation. do you have ideas or any scenarios how to do this?
Re: how to prevent VIP transfer back to it's original node location [message #570495 is a reply to message #570494] Sun, 11 November 2012 05:25 Go to previous messageGo to next message
piotrtal
Messages: 168
Registered: June 2011
Location: Poland/Czestochowa
Senior Member
... or maybe i am wrong. maybe clients are not forced to move theirs current node (make reconnection) after failed node is back again? what is the true?
Re: how to prevent VIP transfer back to it's original node location [message #570496 is a reply to message #570494] Sun, 11 November 2012 06:30 Go to previous messageGo to next message
John Watson
Messages: 8922
Registered: January 2010
Location: Global Village
Senior Member
You misunderstand what will happen following node failure. Think about the node VIPs and listeners (don't worry about the SCAN VIPs and listeners).

Starting point: nodeA has nodeA listener listening on nodeA-vip, and nodeB has nodeB listener listening on nodeB-vip.
Then nodeA fails: now nodeB has nodeB listener listening on nodeB-vip, and nodeA-vip is also active. But nothing is listening on nodeA-vip. All sessions connect to nodeB through nodeB-vip.
Then nodeA restarts: nodeA-vip fails back to nodeA, nodeA listener starts. New session can now start against A or B.

So no sessions will be broken by the fail-back.
Re: how to prevent VIP transfer back to it's original node location [message #570497 is a reply to message #570496] Sun, 11 November 2012 06:52 Go to previous messageGo to next message
piotrtal
Messages: 168
Registered: June 2011
Location: Poland/Czestochowa
Senior Member
thanks John for proffesional answer.

actually i missed listeners in my reasoning - thanks for clarification. i did'nt know that after VIP trasnfering there is nothing listenig on this VIP which was transfered between nodes.
i thoutght that in this case listener on nodeA starts listen on vipA and vipB (on both of vips) - but it was wrong assumption.

but what about services?

lets assume that we have serviceA set as preffered on n1 (node1) and available on n2 (node2)

1. serviceA works on n1
2. n1 fails
3. vip1 goes to n2
3. serviceA goes to n2
4. clients makes failover to n2 --> serviceA using vip2 from n2
5. n1 is ready
6. vip1 goes to n1

and now is question:

6. service is transfered to n1 and forces clients to reconnect to the new place ?
Re: how to prevent VIP transfer back to it's original node location [message #570498 is a reply to message #570496] Sun, 11 November 2012 07:02 Go to previous messageGo to next message
piotrtal
Messages: 168
Registered: June 2011
Location: Poland/Czestochowa
Senior Member
John Watson wrote on Sun, 11 November 2012 13:30

...
Then nodeA fails: now nodeB has nodeB listener listening on nodeB-vip, and nodeA-vip is also active. But nothing is listening on nodeA-vip. All sessions connect to nodeB through nodeB-vip.
...


... and aditional question to those send in previous posts:

so why Clusterware transfer nodeA-vip to the nodeB without making listener listening on this vip? it makes no sense for me.
because in that case clients, who try to connect througnt nodeA-vip gets 'no listener available' and they need to get another entry from theirs tnsnames.ora - in that case nodeB-vip.
the same counld happen without nodeA-vip transfering.
Re: how to prevent VIP transfer back to it's original node location [message #570499 is a reply to message #570498] Sun, 11 November 2012 07:10 Go to previous messageGo to next message
piotrtal
Messages: 168
Registered: June 2011
Location: Poland/Czestochowa
Senior Member
... but you are right. i checked this a while ago. listener works only on local VIP after another node fails. other VIP is transfered but reconfiguration of listener doesn't take place.
Re: how to prevent VIP transfer back to it's original node location [message #570501 is a reply to message #570499] Sun, 11 November 2012 07:35 Go to previous messageGo to next message
John Watson
Messages: 8922
Registered: January 2010
Location: Global Village
Senior Member
You have it sussed! And to complete the answer, check the behaviour of your services: failover is automatic, but do they failback? And note the "-f" switch for "srvctl relocate service".
Re: how to prevent VIP transfer back to it's original node location [message #570503 is a reply to message #570501] Sun, 11 November 2012 07:41 Go to previous messageGo to next message
piotrtal
Messages: 168
Registered: June 2011
Location: Poland/Czestochowa
Senior Member
thanks. now everything is clear...

(except sense of VIP relocating without local listener reconfiguration to use it) Wink
Re: how to prevent VIP transfer back to it's original node location [message #570518 is a reply to message #570494] Sun, 11 November 2012 16:43 Go to previous messageGo to next message
mkounalis
Messages: 147
Registered: October 2009
Location: Dallas, TX
Senior Member
The VIP ip address is plumbed on another node so that the client can receive an end of channel signal, and that allows the client to fail over either by using java pool rules or by sqlnet failover. If the VIP ip isn't plumbed on another node, then the tcp/ip timeout would apply, which is usually five minutes. The listeners are only involved in setting up the sqlnet client connection - they are not involved past that. So any session existing on a server won't be effected by anything other than a service change. It is always a good idea to configure services to run on more than a single node for this reason. After a node is brought back up online, the VIP would start on that node, and a listener would then start listening on that VIP ip's address. New sessions would then start on this node. It's usually not necessary to force a session to fail back over, unless the RAC cluster is improperly sized in that their are not enough nodes or horsepower to absorb a failed node. It's always important to size a cluster and tune it to run so that each node is not at 100% capacity and is then capable of absorbing the workload of a failed node.
Re: how to prevent VIP transfer back to it's original node location [message #570542 is a reply to message #570518] Mon, 12 November 2012 00:39 Go to previous messageGo to next message
piotrtal
Messages: 168
Registered: June 2011
Location: Poland/Czestochowa
Senior Member
mkounalis wrote on Sun, 11 November 2012 23:43
The VIP ip address is plumbed on another node so that the client can receive an end of channel signal, and that allows the client to fail over either by using java pool rules or by sqlnet failover. If the VIP ip isn't plumbed on another node, then the tcp/ip timeout would apply, which is usually five minutes. The listeners are only involved in setting up the sqlnet client connection - they are not involved past that. So any session existing on a server won't be effected by anything other than a service change. It is always a good idea to configure services to run on more than a single node for this reason. After a node is brought back up online, the VIP would start on that node, and a listener would then start listening on that VIP ip's address. New sessions would then start on this node. It's usually not necessary to force a session to fail back over, unless the RAC cluster is improperly sized in that their are not enough nodes or horsepower to absorb a failed node. It's always important to size a cluster and tune it to run so that each node is not at 100% capacity and is then capable of absorbing the workload of a failed node.


thanks for this answer (thanks John too). its clear now.

i know that clients could wait for TCPtimeout after VIP dissaperar (and it takes aproximetly couple of minutes), and it reconnection is done quicker if we transfer VIP to another node. but i didn't know that after VIP failover listener doen't reconfigure itself to listen on this VIP. but probably it is done intentionally, because timeout won't appear but clients receive information that there no listener on specified VIP and make connection to another one.

thanks again.
Re: how to prevent VIP transfer back to it's original node location [message #571091 is a reply to message #570542] Wed, 21 November 2012 01:14 Go to previous messageGo to next message
lerry_wu
Messages: 12
Registered: December 2011
Junior Member
I have a question. If RAC1 is down,then rac1-vip transfer to rac2,and the rac1 listening on the rac2.
I want to know if we can connect to rac1 using rac1 IP or we only can connec to rac2.

Re: how to prevent VIP transfer back to it's original node location [message #571097 is a reply to message #571091] Wed, 21 November 2012 01:34 Go to previous message
mkounalis
Messages: 147
Registered: October 2009
Location: Dallas, TX
Senior Member
Only the IP address fails over to another node - and again this is ONLY to force open sessions to get immediate notification that their sessions are now dead and to handle them however they have cofigured that situation to be handled. So, if the VIP for RAC1 moves to RAC2, nothing oracle wise is listening on that IP address, so SQLNET connections would only be accomodated b the listener running on RAC2 which is listening to the RAC2 VIP ip. Please read the RAC concepts guides located on docs.oracle.com.

Previous Topic: RAC and its behaviour
Next Topic: CRS-4535: Cannot communicate with Cluster Ready Services
Goto Forum:
  


Current Time: Thu Mar 28 15:31:06 CDT 2024