Re: RAC, extra nodes, load-balancing and failover

Howard, Group,

> >
> > If we add an extra node and instance (add redo-, add undo-ts, add public
> thread...)
> > and start the instance, say instance i3 on node n3,
> > will new incoming connections be able to connect to it, and will
> load-balancing
> > occur over the additional node as well as over the existing nodes ?
> >
>
> Depends. What are clients connecting to at the moment? If they are
> connecting to a specific instance then (1) you're missing the point and (2)
> no. If they are connecting to the RAC service, then yes, they may well be
> directed to the new node, because that what Listeners do.

Correction and recap :
Current clients have one single tns-entry for the RAC database, which includes the two (or more) known nodes at starting time, including failover and load-balance.
That works for our 2 nodes,
but we only had two, no way to test with 3 or more (and the loaner system has gone yesterday...)

Questions now becomes :
given fact that the client-tns only knows of two destination ip-addresses for the rac-db, will its connections still get distributed over >2 instances even if when we can only tweak the listener.ora and tnsnames.ora on the servers when we add more nodes ?

Your answer seems to confirm that, YES, new nodes can becomem part of the load-balancing cluster.

Next Question :
Will failover work for connections that have ended up on the new nodes, e.g. those nodes not yet known to the tns on the client?   

> Then you haven't configured the tnsnames.ora correctly, and have
> misunderstood what RAC is all about.

I hope not, but if so,Im trying to correct that :-)

> Who knows. Failover is a product of a correctly configured tnsnames (or
> equivalent) which you haven't got, and the use of OCI, which I wouldn't know
> about.

I'll try to stay away from OCI calls for the moment. that is too long ago.

> > nb: apologies or not reading the whole FM (for sqlnet) up front.
> >
> > Any thoughts ?
> >
> > Regards,
> >
> > PdV
Received on Fri Dec 13 2002 - 12:21:38 CST