SQL Server Failover: The network path was not found - until after reboot

Question

I am facing a problem in our an environment where there is 2 SQL Servers in a failover configuration. So if one becomes unavailable the other takes over.

Now these servers switches roles every now and then, so one server goes from being master to slave and back.

Whenever this happens we get some SQL Errors, now i was under the impression that the .NET framework should be able to handle this scenario, however it's not but for now that is not so critical if we can just recover from it.

BUT it seems like we now have a situation where ones they did the switch, our WebAPI application just refuses to ever recover and it keeps giving the error.

If we reboot the application pool however, things seem to go back to normal.

Each SqlConnection object is always disposed after use, and they are created with a connection string that provides the failover partner:

Data Source=Server_1.Domain; Initial Catalog=database_name;User ID=db_user;Password=user_pass;Failover Partner=Server_2.Domain

The server and the Application lives in separate domains if that matters.

Now if this just lasted while they where switching roles it would be fine, but I don't quite get why it persists.

I can find countless threads here on StackOverflow about the issue, but they all seem to have the issue at a consistent state, where this is not as much consistent.

So all the usual "Allow remote connections", enable "TCP/IP", Open ports etc should all be in order, otherwise we shouldn't be able to connect at all.

I am also a bit confused about seeing a "Named Pipes Provider, error: 40", shouldn't it use TCP/IP when its not the same machine? oO..

Here are some more error details.

---

[Win32Exception (0x80004005): The network path was not found]

[SqlException (0x80131904): A network-related or instance-specific error occurred while establishing a connection to SQL Server. The server was not found or was not accessible. Verify that the instance name is correct and that SQL Server is configured to allow remote connections. (provider: Named Pipes Provider, error: 40 - Could not open a connection to SQL Server)]
   System.Data.ProviderBase.DbConnectionPool.TryGetConnection(DbConnection owningObject, UInt32 waitForMultipleObjectsTimeout, Boolean allowCreate, Boolean onlyOneCheckConnection, DbConnectionOptions userOptions, DbConnectionInternal& connection) +642
   System.Data.ProviderBase.DbConnectionPool.TryGetConnection(DbConnection owningObject, TaskCompletionSource`1 retry, DbConnectionOptions userOptions, DbConnectionInternal& connection) +116
   System.Data.ProviderBase.DbConnectionFactory.TryGetConnection(DbConnection owningConnection, TaskCompletionSource`1 retry, DbConnectionOptions userOptions, DbConnectionInternal oldConnection, DbConnectionInternal& connection) +1079
   System.Data.ProviderBase.DbConnectionInternal.TryOpenConnectionInternal(DbConnection outerConnection, DbConnectionFactory connectionFactory, TaskCompletionSource`1 retry, DbConnectionOptions userOptions) +6600667
   System.Data.SqlClient.SqlConnection.TryOpenInner(TaskCompletionSource`1 retry) +233
   System.Data.SqlClient.SqlConnection.TryOpen(TaskCompletionSource`1 retry) +278
   System.Data.SqlClient.SqlConnection.Open() +239

I am hoping someone might have seen something like this before and can provide a hint or two?

Answer 1

We never really cracked this. Not even with an SQL Server consultant on premise. Instead he pointed us in a different direction which was Availability groups.

Since we could not do that right away, for now we use a DNS alias for the SQL server, if the primary server goes down we switch the alias to point to the other. This is not automatically but at least the above error does not occur under that scenario ones the DNS is switched.