Re: SCAN addresses and TNSNames

The scan listener should fail over to the surviving node, so it should be presenting all 3 vip’s from that node.

I’d check that happened, and also that the client is pointing at the scan listener.

Neil.
sent from my phone

> On 2 Oct 2019, at 18:51, William Beldman <wbeldma_at_uwo.ca> wrote:
>
> I find the documentation on both SCAN addresses and TNSNames entries is good
> but is still missing some details.
>
> I have a two node RAC cluster:
> =====
> $ srvctl status scan_listener
> SCAN Listener LISTENER_SCAN1 is enabled
> SCAN listener LISTENER_SCAN1 is running on node <NODE 2>
> SCAN Listener LISTENER_SCAN2 is enabled
> SCAN listener LISTENER_SCAN2 is running on node <NODE 1>
> SCAN Listener LISTENER_SCAN3 is enabled
> SCAN listener LISTENER_SCAN3 is running on node <NODE 1>
> =====
>
> My DNS resolves my SCAN address to 3 different IPs (and I can confirm DNS
> round-robin is working, the order is different everytime):
> =====
> $ nslookup dm01-scan.<suffix>
> Server: 127.0.1.1
> Address: 127.0.1.1#53
>
> Name: dm01-scan.<suffix>
> Address: <IP 1>
> Name: dm01-scan.<suffix>
> Address: <IP 2>
> Name: dm01-scan.<suffix>
> Address: <IP 3>
> =====
>
> My TNSNames entry is very basic:
> =====
> (DESCRIPTION =
> (ADDRESS_LIST =
> (ADDRESS = (PROTOCOL = TCP)(HOST = dm01-scan.<suffix>)(PORT = 1521)))
> (CONNECT_DATA = (SERVICE_NAME = <service name>)
> )
> )
> =====
>
> We had a crash on one of the nodes (at least it looks like only one) and some
> of my processes could not establish a connection to the database. If I was
> unlucky, I *think* this means 2 out of my 3 scan listeners was not working.
>
> So I'd like to understand the behavior on the client side when that happens.
>
> What I suspect happened was when my client attempted to connect to the
> database, DNS returned a bad IP first, and my client connection failed and
> gave up.
>
> If so, would supplying retry and delay parameters mitigate this issue? More
> importantly, if I do not supply these parameters, what's the default behavior
> and where is that documented? What if it keeps returning a bad IP first?
>
> Also, in the event of a sudden disconnect of an ALREADY established
> connection, is there any TNSNames parameters I can supply to ask the process
> to either "pause and wait for the database to come back" or "re-establish your
> connection to the same scan address again"? Could I perhaps use the "failover"
> parameter but have the failover address just be the same scan address?
†Ûiÿü0ÁúÞzX¬¶Ê+ƒün– {ú+iÉ^ Received on Wed Oct 02 2019 - 20:07:22 CEST