December 17, 2013 at 12:47 pm
Hello everyone,
I have an interesting dilemma and would like some input on what the issue could possible be.
I am trying to implement AlwaysOn with the current database application we use in house. This client application connect directly to the database to make changes.
I have setup a test environment using AlwaysOn with this client and have run into an issue where it will connect to the listener and make changes to the primary database, however, when i do a manual failover or actually take a server down, the secondary takes up the primary role and is waiting for incoming connections.
I can connect via SSMS and it shows me that i have connected to the secondary server viewing the database setup with AlwaysOn, however, when I try to connect via the client app it crashes every time which it does when it cannot connect to the database. When i fail the system back to the original primary server it works like a charm.
I have been trying to figure out the possible reason for this. My only conclusion is the client app, when it connects to the listener, takes note of the current active database server and caches that someplace. This program we use is not built in house so we have not control on how it communicates and connects.
Does anyone have any thoughts or ideas i could try out or recommend to the software company to make their client work properly with AlwaysOn tech? Any thoughts and ideas will be greatly appreciated!
Thank you,
December 17, 2013 at 9:00 pm
Look at the SQL errorlog and are there any login failures?
December 18, 2013 at 2:44 am
I've had this happen but after a few seconds, it would connect or after a ipconfig/flushdns
Check the registry entries for you App for any reference to the server name instead of the listener.
December 18, 2013 at 11:36 am
Ravid_ds (12/17/2013)
Look at the SQL errorlog and are there any login failures?
There were not errors in the log. It is appearing the client can no longer connect to the database server after the failover. It is almost as if this client is caching the primary server someplace and is trying to still connect to the primary database.
December 18, 2013 at 11:38 am
SQLSACT (12/18/2013)
I've had this happen but after a few seconds, it would connect or after a ipconfig/flushdnsCheck the registry entries for you App for any reference to the server name instead of the listener.
I too tried restarting the service for the server and clearing DNS cache with no luck. Unfortunately the client does not write to the registry.
December 18, 2013 at 11:43 am
Just curious, but could DNS help solve this? I don't know enough to know how, so I'm just wondering if someone else might be able to suggest a methodology?
Steve (aka sgmunson) 🙂 🙂 🙂
Rent Servers for Income (picks and shovels strategy)
December 19, 2013 at 10:30 am
What driver is your client application using to connect? ODBC, ado etc etc.
Also I assume you have checked that the connection string is using the listener name for your AG and not just the server name the AG was on the primary on prior to failover?
MCITP SQL 2005, MCSA SQL 2012
Viewing 7 posts - 1 through 6 (of 6 total)
You must be logged in to reply to this topic. Login to reply