This content has been marked as final. Show 3 replies
If one assumed you were correct about how RAC works, you are not, I am fascinated by you think you need to avoid a behavior that works well for everyone else. Care to explain what makes your requirement different?
The reality however is not what you assume. RAC does not fail over connections for purposes of load balancing. New connections will go to the node that has joined the cluster until balance is achieved. If there are no new connections it will remain essentially unused.
Note to anyone that doesn't like my answer: Please note the OP did not give us any information on version or load balancing so I just punted the ball in the general direction of the goal posts.
everything is logic for me until clients are not forced to reconnect to the older node after its available again. this was my concern. i didn't know that.
now i know that clients won't be forced to failback after node will be available again and everything is clear for me.
... they just stay on the node where they connect after failover.
in case to move them intentionally we need to invoke -f (force) option to relocate them forcibly.
i was wondering what happen if we have such scenario:
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
7. service is transfered to n1 and forces clients to reconnect to the new place ?
but now i know that they wont be forced to reconnect. after n1 is available again serviceA stays on n2 (as available).
thanks for answer.
and aditionally, i found out that after VIP-B is transfered to available nodeA, listener from this node wont be listen on this VIP-B, and clients won't be able to do reconnection throught this VIP-B, they use VIP-A.
know about this behavior makes everything looks logic now.
Edited by: piotrtal on Nov 12, 2012 7:50 AM