locked
Question about Asynchronous Mirroring and Failover RRS feed

  • Question

  • I am trying to document... what to do when a disaster does happen.. and we need to failover the mirrored databases.  It's been a while... so my memory of mirroring is getting hazy.  I have asynchronous mirror with no witness.  I was planning to suggest the following protocol.  Please let me know if I have this right?

    1) If you need to failover and the principal is still up.  Attempt to set SAFETY ON and then perform manual failover: ALTER DATABASE database_name SET PARTNER FAILOVER

    2) If you need to failover and the principal is still up.  But you couldn't do step 1.  Attempt to backup the log on the principal, stop mirroring, restore log onto mirror with recovery, and then recreate the mirror.

    3) Step 1 and 2 didn't work or principal is down.  Issue the command: ALTER DATABASE <database_name> SET PARTNER FORCE_SERVICE_ALLOW_DATA_LOSS. 

    Friday, March 25, 2011 4:12 PM

Answers

  • Responding to Failure of the Principal  -Asynchronous mirroing

    When the principal fails, the database owner has several choices, as follows:

    • Leave the database unavailable until the principal becomes available again.

      If the principal database and its transaction log are intact, this choice preserves all of the committed transactions at the expense of availability.

    • Stop the database mirroring session, manually update the database, and then begin a new database mirroring session.

      If the principal database is lost but the principal server is still running, immediately attempt to back up the tail of the log on the principal database. If the tail-log backup succeeds, removing mirroring may be your best alternative. After removing mirroring, you can restore the log onto the former mirror database, which preserves all of the data.

    In the High Performance (Asynchronous) operating mode, transactional safety is OFF, and the transfer of log records is asynchronous. The principal server does not wait for an acknowledgement from the mirror that all transaction log records have been recorded on the mirror. The mirror does its best to keep up with the principal, but it is not guaranteed at any point in time that all the most recent transactions from the principal will have been hardened in the mirror's transaction log.

    Since the safety is OFF, automatic failover is not possible, because of possible data loss; therefore, a witness server is not recommended to be configured for this scenario. If the witness is set, a quorum is required. If the witness is not set, then a quorum is not required. Manual failover is not enabled for the High Performance mode. The only type of failover allowed is forced service failover, which is also a manual operation:

    ALTER DATABASE <dbname> SET PARTNER FORCE_SERVICE_ALLOW_DATA_LOSS
    

    The forced service failover causes an immediate recovery of the mirror database. It may involve potential data loss on the mirror when it is recovered, if some of the transaction log blocks from the principal have not yet been received by the mirror. The High Performance mode is best used for transferring data over long distances (that is, for disaster recovery to a remote site), or for mirroring very active databases where some potential data loss is acceptable.

    For more please visit here http://technet.microsoft.com/en-us/library/cc917680.aspx

    Friday, March 25, 2011 8:01 PM