| how to prevent VIP transfer back to it's original node location [message #570494] |
Sun, 11 November 2012 05:10  |
 |
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 #570496 is a reply to message #570494] |
Sun, 11 November 2012 06:30  |
John Watson
Messages: 8962
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 #570518 is a reply to message #570494] |
Sun, 11 November 2012 16:43 |
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 |
|
piotrtal
Messages: 168
Registered: June 2011
Location: Poland/Czestochowa
|
Senior Member |
|
|
mkounalis wrote on Sun, 11 November 2012 23:43The 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 #571097 is a reply to message #571091] |
Wed, 21 November 2012 01:34 |
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.
|
|
|
|
] 
Blog
Search
Help
Members
Register
Login
Home
