
How Automatic Failover Works
Under the preceding conditions, automatic failover initiates the following sequence of actions:
-
If the principal server is still running, it changes the state of the principal database to DISCONNECTED and disconnects all clients from the principal database.
-
The witness and mirror servers register that the principal server is unavailable.
-
If any log is waiting in the redo queue, the mirror server finishes rolling forward the mirror database.
Note: |
|---|
|
The amount of time required to apply the log depends on the speed of the system, the recent work load, and the amount of log in the redo queue.
|
-
The former mirror database moves online as the new principal database, and recovery cleans up all uncommitted transactions by rolling them back as quickly as possible. Locks isolate those transactions.
-
When the former principal server rejoins the session, it recognizes that its failover partner now owns the principal role. The former principal server takes on the role of mirror, making its database the mirror database. The new mirror server synchronizes the new mirror database with the principal database as quickly as possible. As soon as the new mirror server has resynchronized the databases, failover is again possible, but in the reverse direction.
The following illustration shows a single instance of automatic failover.
Initially, all three servers are connected (the session has full quorum). Partner_A is the principal server and Partner_B is the mirror server. Partner_A (or the principal database on Partner_A) becomes unavailable. The witness and Partner_B both recognize that the principal is no longer available the session retains quorum. Partner_B becomes the principal server and makes its copy of the database available as the new principal database. Eventually, Partner_A reconnects to the session and discovers that Partner_B now owns the principal role. Partner_A then takes on the mirror role.
After failover, clients must reconnect to the current principal database. For more information, see Connecting Clients to a Mirrored Database.
Note: |
|---|
|
Transactions that have been prepared using the Microsoft Distributed Transaction Coordinator but are still not committed when a failover occurs, are considered aborted after the database has failed over.
|