Reconnecting to a Database Mirroring Session
New: 14 April 2006
If an established connection to a database mirroring session fails for any reason, for example, due to a database mirroring failover, and the application attempts to reconnect to the initial server, the data access provider can attempt to reconnect using the failover partner name stored in the client's cache. Reconnecting is not automatic, however. The application must become aware of the error. Then, the application needs to close the failed connection and open a new connection using the same connection string attributes. At this point, the data access provider redirects the connection to the failover partner. If the server instance identified by this name is currently the principal server, the connection attempt usually succeeds. If it is unclear whether a transaction was committed or rolled back, the application must check on the state of the transaction, in the same way as when reconnecting to a stand-alone server instance.
Reconnecting resembles an initial connection for which the connection string supplied a failover partner name. If the first connection attempt fails, connection attempts alternate back and forth between the initial partner name and failover partner name until either the client connects to the principal server or the data access provider times out.
Note
SQL Native Client verifies that it connects to a principal server instance but not whether this instance is the partner of server instance specified in the initial partner name of the connection string.
If the connections use TCP/IP and the client uses Windows XP or later, the connection retry algorithm determines the amount of time allotted to the connection attempts in each round. For more information, see Connection Retry Algorithm (for TCP/IP Connections).
Important
If the client gets disconnected from the database, the data access provider does not attempt to reconnect. The client must issue a new connection request. Also, if an application shuts down on losing the connection, it will lose the cached partner names. If the connection was lost because the principal server became unavailable, the only way that the application can reconnect to the mirror server is by supplying the failover partner name in its connection string.
Impact of Redirection on a Client Application
After a failover, the data access provider redirects the connection to the current principal server instance. However, the redirection is transparent to clients. To a client, a redirected connection appears to be a connection to the server instance identified by the initial partner name. When the initial partner is currently the mirror server, the client can appear to be connected to the mirror server and updating the mirror database. Actually, however, the client has been redirected to the failover partner, which is the current principal database, and the client is updating the new principal database.
After being redirected to the failover partner, a client can experience unexpected results when using a Transact-SQL USE statement to use a different database. This can happen if the current principal server instance (the failover partner) has a different set of databases than the original principal server (the initial partner).
See Also
Concepts
Connection Retry Algorithm (for TCP/IP Connections)
Network Protocols, and TDS Endpoints
Overview of Database Mirroring
Possible Failures During Database Mirroring
Other Resources
Connecting to the SQL Server Database Engine
Using Connection String Keywords with SQL Native Client
Using SQL Server Browser