Role Switching During a Database Mirroring Session
Within the context of a database mirroring session, the principal and mirror roles are typically interchangeable in a process known as role switching. In role switching, the mirror server acts as the failover partner for the principal server, taking over the principal role, recovering its copy of the database and bringing it online as the new principal database. The former principal server, when available, assumes the mirror role, and its database becomes the new mirror database. Potentially, the roles can switch back and forth either in response to multiple failures or for administrative purposes.
Note
This topic assumes that you are familiar with the database mirroring operating modes. For more information, see Asynchronous Database Mirroring (High-Performance Mode) and Synchronous Database Mirroring (High-Safety Mode).
The following illustration shows mirroring partners, Partner_A and Partner_B, switching the principal and mirror roles over a series of automatic or manual failovers.
.gif "Partners switching twice between roles")
Important
After a role switch, jobs that ran on the former principal database must be recreated on the new principal server to run there. For more information, see Managing Logins and Jobs After Role Switching.
Three types of role switching exist: automatic failover , manual failover, and forced service (with possible data loss). Support for each form depends on the operating mode of the session.
Note
If you are unfamiliar with these operating modes, see Database Mirroring Sessions.
Manual failover
High-safety mode supports manual failover. Whenever the database is synchronized, the database owner can initiate a manual failover.
Manual failover is provided for administrative purposes. For more information, see Manual Failover.Automatic failover
In the presence of a witness, high-safety mode supports automatic failover. Automatic failover occurs only on the loss of the principal server when the witness and mirror server are still connected to each other and the database is already synchronized. For more information, see Automatic Failover.Force service (with possible data loss)
Forcing service is supported in high-safety mode when no witness is set and in high-performance mode. On the loss of the principal server, the database owner can make the database available by forcing service to the mirror server (with possible data loss).Note
We recommend that the WITNESS property be set to OFF in high-performance mode. Otherwise, to bring the database online, the mirror server must connected to the witness. For more information, see Forced Service (with Possible Data Loss).
The following table summarizes which forms of failover are supported under each of the operating modes.
| High performance | High-safety mode without a witness | High-safety mode with a witness | |
|---|---|---|---|
Automatic failover |
No |
No |
Yes |
Manual failover |
No |
Yes |
Yes |
Forced service |
Yes |
Yes |
No |
After a role switch, certain metadata must exist on both partners to ensure that all of the database users can access the new principal database. In addition, backup jobs must be created on the new principal server, to ensure that the database continues to be backed up on its regular schedule. For more information, see Managing Logins and Jobs After Role Switching.
During a role switch, the amount of time that database mirroring will be out of service depends on the type of role switching and on the cause. For more information, see Estimating the Interruption of Service During Role Switching.
See Also
Concepts
Asynchronous Database Mirroring (High-Performance Mode)
Estimating the Interruption of Service During Role Switching
Database Mirroring Witness
Synchronous Database Mirroring (High-Safety Mode)
Mirroring States
Database Mirroring Sessions