Routing all connections through a one node in a 2 node RAC cluster

Question

Hi everyone
My client has the following requirement: an active/active RAC cluster (eg node1/node2), but with only one of the nodes being used (node1) and the other sitting there just in case.
For things like services, i'm sure this is straightforward enough - just have them set to preferred on node1 and available on node 2.
For connections, I imagine I would just have the vips in order in the tns file, but with LOAD_BALANCING=OFF, so they go through the tns entries in order (i.e node 1, then node 2), so this would still allow the vip to failover if node 1 is down.
Does that sound about right? Have I missed anything?
Many thanks
Rup

Answer 1

user573914 wrote:
My client has the following requirement: an active/active RAC cluster (eg node1/node2), but with only one of the nodes being used (node1) and the other sitting there just in case.Why? What is the reason for a "+just in case+" node - and when and how is is "enabled" when that just-in-case situation occurs?
This does not many any kind of sense from a high availability or redundancy view.
For connections, I imagine I would just have the vips in order in the tns file, but with LOAD_BALANCING=OFF, so they go through the tns entries in order (i.e node 1, then node 2), so this would still allow the vip to failover if node 1 is down.
Does that sound about right? Have I missed anything?Won't work on 10g - may not work on 11g. The Listener can and does handoff connections, depending on what the TNS connection string say. If you do not connect via a SID entry but via a SERVICE entry, and that service is available on multiple nodes, you may not (and often will not) be connected to instance on the single IP that you used in your TNS connection.
Basic example:
// note that this TEST-RAC alias refers to a single specific IP of a cluster, and use
// SERVICE_NAME as the request
/home/billy> tnsping test-rac
TNS Ping Utility for Linux: Version 10.2.0.1.0 - Production on 18-JAN-2011 09:06:33
Copyright (c) 1997, 2005, Oracle.  All rights reserved.
Used parameter files:
/usr/lib/oracle/xe/app/oracle/product/10.2.0/server/network/admin/sqlnet.ora
Used TNSNAMES adapter to resolve the alias
Attempting to contact (DESCRIPTION = (ADDRESS=(PROTOCOL=TCP)(HOST= 196.1.83.116)(PORT=1521)) (LOAD_BALANCE=no) (CONNECT_DATA=(SERVER=shared)(SERVICE_NAME=myservicename)))
OK (50 msec)
// now connecting to the cluster using this TEST-RAC TNS alias - and despite we listing a single
// IP in our TNS connection, we are handed off to a different RAC node (as the service is available
// on all nodes)
// and this also happens despite our TNS connection explicitly requesting no load balancing
/home/billy> sqlplus scott/tiger@test-rac
SQL*Plus: Release 10.2.0.1.0 - Production on Tue Jan 18 09:06:38 2011
Copyright (c) 1982, 2005, Oracle.  All rights reserved.
Connected to:
Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 - 64bit Production
With the Partitioning, Real Application Clusters, Data Mining and Real Application Testing options
SQL> !lsof -n -p $PPID | grep TCP
sqlplus 5432 billy    8u  IPv4 2199967      0t0     TCP 10.251.93.58:33220->196.1.83.127:37031 (ESTABLISHED)
SQL> So we connected to RAC node 196.1.83.116 - and that listener handed us off to RAC node 196.1.83.127. The 11gr2 Listener seems to behave differently - it does not do a handoff (from a quick test I did on a 11.2.0.1 RAC) in the above scenario.
This issue aside - how do you deal with just-in-case situation? How do you get clients to connect to node 2 when node 1 is down? Do you rely on the virtual IP of node 1 to be switched to node 2? Is this a 100% safe and guaranteed method?
It can take some time (minutes, perhaps more) for a virtual IP address to fail over to another node. During that time, any client connection using that virtual IP will fail. Is this acceptable?
I dunno - I dislike this concept of your client of treating the one RAC node as some kind of standby database for a just-in-case situation. I fail to see any logic in that approach.