Role switches (failovers) in database mirroring

If the primary server becomes unavailable because of hardware or software failure, the mirror server negotiates with the arbiter to take ownership of the database and assume the role of primary server. For an ownership transfer, or role switch, to take place, the surviving partner server and the arbiter must agree that the mirror was in a current, synchronized state at the time the role switch is attempted.

Any clients that were connected to the original primary server are disconnected, and any uncommitted transactions are lost. Clients must then reconnect to the database on the new primary server to continue accessing the database. When the original primary server becomes available again, it assumes the role of mirror server.
Any clients that were connected to the original mirror database are maintained when failover occurs and the mirror server becomes the primary server. After failover, these client connections can make changes to the database.

The database servers display status messages in the database server messages window on startup to indicate which role the server is assuming and how far the startup process has progressed. A message appears if the database must be restarted because of the loss of one or more of the other servers in the mirroring system, or if its role changes from mirror to primary.

If an assertion failure occurs on a server that is part of a mirroring system, the server writes the error to the database server message log and then exits. This notifies the other servers that it has failed so that they can take appropriate action.

If a database involved in a high availability environment encounters a problem, such as an incompatible or mismatched transaction log, it is stopped. The database server running the problem database also shuts down unless there are other databases running on it.

Details about the state of each database in the database mirroring system are stored in a state information file.

When an arbiter is present, failover from primary to mirror is automatic. If you are running in synchronous mode, no committed transactions are lost during failover.
Failover is very fast because the mirror server has already applied the transaction log. When the mirror detects that the primary has failed, it rolls back any uncommitted transactions and then makes the database available.

If the primary becomes unavailable while it is in a state of synchronizing, then the mirror cannot take over as the primary. The mirroring system waits for the primary to become available.

SQL Anywhere supports system events that fire when failover occurs in a database mirroring system, regardless of which mode you are using. You can use these events for such tasks as notifying the administrator when failover occurs.

Role switches (failovers) in database mirroring

See also