Assuming it was <NODE 1> that crashed, are you suggesting if I happened to
check on <NODE 2> at that time, I would have seen:
=====
$ 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 2>
SCAN Listener LISTENER_SCAN3 is enabled
SCAN listener LISTENER_SCAN3 is running on node <NODE 2>
=====
And my DNS would have punted all three IPs to <NODE 2>?
How do I verify whether or not this actually occurred?
The client is definitely configured to hit the scan address. That is not in
question.
On Wednesday October 2 2019 06:07:22 PM Neil Chandler wrote:
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.but is still missing some details.
sent from my phone
On 2 Oct 2019, at 18:51, William Beldman <wbeldma@xxxxxx> wrote:
I find the documentation on both SCAN addresses and TNSNames entries is
good
of my processes could not establish a connection to the database.
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
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.
gave up.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
importantly, if I do not supply these parameters, what's the
If so, would supplying retry and delay parameters mitigate this issue?
More
to either "pause and wait for the database to come back" ordefault 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
"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?
Attachment:
signature.asc
Description: This is a digitally signed message part.
