Last week I had to set up a mirror while an existing log shipping solution was in place. The aim was to have the mirror as an asynchronous mirror (possibly upgraded to synchronous in future, depending on performance), but still have the log shipping solution as an offsite backup.
To initialise a mirror, you need to have the database restored to a point where the current transaction log on the principle is able to be applied. As log shipping is constantly taking backups, it is necessary to constantly restore each log backup to keep the un-activated mirror ready to synchronise. In this situation, we manually copied the log backups over to the mirror, and allowed our log shipping scripts to automatically apply any log backups it found.
When ready to turn on the mirror, we paused the log backup job, turned on the mirror, and allowed the two to synchronise. After that, we turned the job back on, and it took backups as normal.
The one thing to watch out for when doing log shipping with mirroring is that only transactions that have been applied to both the principle and the mirror will be backed up. This means that if the mirror goes offline for any reason, the transaction log will continue to grow, no matter how many times you try to back it up. Once the mirror comes back online, all those transactions will be applied to the mirror, and the transaction will be able to be backed up. This is a possible risk, if your transaction log can get full quickly.
The mirror was successful, and no problems have risen. I’ll describe mirror monitoring strategies in a future post.