Database mirroring scenarios

The following scenarios help you understand what happens when a server becomes unavailable in a mirroring system. The scenarios use the following database mirroring configuration, which consists of Server 1, Server 2, and an arbiter server running in synchronous mode:

An example database mirroring system, consisting of Server 1, Server 2, and an arbiter server.

At any time, you can use the MirrorState, PartnerState, and ArbiterState database properties to determine the status of the database servers in the mirroring system. See Database properties.

Scenario 1: Primary server becomes unavailable

The primary server (Server 1) becomes unavailable. All clients are disconnected.
The arbiter and Server 2 detect that Server1 is no longer available.
The arbiter and Server 2 reach quorum, and Server 2 becomes the primary server.
Server 2 begins accepting client connections.

In this scenario, if you are running in asynchronous or asyncfullpage mode and did not specify that autofailover should occur, then you may need to make a copy of the database and restart the server that is still operational before clients can connect again.

For more information about recovering when the primary server becomes unavailable, see Recovering from primary server failure.

Scenario 2: Primary server becomes unavailable and then restarts

The primary server (Server 1) becomes unavailable. All clients are disconnected.
The arbiter and mirror server (Server 2) detect that the primary server (Server 1) is no longer available.
The arbiter and Server 2 reach quorum, and Server 2 becomes the primary server.
Server 2 begins accepting client connections.
Server 1 comes back online and reconnects to Server 2 and the arbiter.
Server 1 requests quorum, but Server 2 is already the primary server.
Server 1 is the mirror server, and waits for changes from Server 2.
Server 2 sends changes to Server 1.

Should Server 2 become unavailable before Server 1 has received all the transactions from Server 2, Server 1 will not be able to reach a synchronized state. It must wait for Server 2 to become available again so it can obtain and apply the transactions it does not yet have.

For more information about recovering when the primary server becomes unavailable, see Recovering from primary server failure.

Scenario 3: Mirror server becomes unavailable

The mirror server (Server 2) becomes unavailable.
The arbiter and Server 1 detect that the mirror server (Server 2) is no longer available.

Client connections are not affected. They can continue to connect to the primary server. However, if either Server 1 or the arbiter server becomes unavailable, the clients will not be able to connect.

Scenario 4: Mirror server becomes unavailable and then restarts

The mirror server (Server 2) becomes unavailable.
Client connections are not affected because there is no change in availability. They can continue to connect to the primary server. However, if either Server 1 or the arbiter server becomes unavailable, then clients will not be able to connect.
Server 2 comes back online and reconnects to Server 1 and the arbiter.
Server 2 requests quorum, but Server 1 is already the primary server.
Server 2 is the mirror server, and waits for changes from Server 1.
Server 1 sends changes to Server 2.

Client connections are not affected because there is no change in availability. They continue connecting to Server 1.

Scenario 5: Arbiter becomes unavailable

Server 1 (primary server) and Server 2 (mirror server) detect that the arbiter is gone.
Both servers remain available. Clients are not disconnected.

When the arbiter comes back online, Server 1 and Server 2 will detect it, and begin communicating with it. There is no change in database availability for clients.

If Server 1 or Server 2 becomes unavailable when there isn't an arbiter server, the other server cannot reach quorum by itself, and the database will not be available.

Scenario 6: Arbiter restarts

Discuss this page in DocCommentXchange.