Asynchronously mirroring a SharePoint 2007 Content Database between Two Farms

Recently, I triumphantly setup an asynchronous content mirror between two separate SharePoint farms.

My SharePoint architecture consists of two separate farms in two different cities (San Diego and Las Vegas), both accessible over a corporate intranet.  Each farm is unique and the configuration and administration databases contain unique information that cannot be mirrored from one site to another. The technique outlined below works, however, because the content databases are identical between the two sites and that is the only information that must be mirrored. One farm is a fail over for the other farm, so each farm contains the same sites.  

After searching the Internet for information on how to mirror SharePoint data, I only found one MSDN article which stated that it should be done either with SQL Server clustering or with synchronous mirroring requiring a witness server.  Eventually I found a picture in the MSDN showing a way to mirror only the SharePoint content databases between two farms asynchronously.  

This picture outlined what I wanted, but I knew SharePoint well enough to know it was going to cause problems. I decided to try my hand at a solution, nevertheless. I started on the primary farm in Las Vegas, where I set up mirroring on the Sharepoint_Content database and mirrored it to the Sharepoint_Content database in San Diego, which was designated as the backup farm.  By design, the San Diego content database was inaccessible while the mirroring was in place, so I had little chance of the backup farm actually loading up any pages. This was acceptable, however, because the backup farm did not need to work unless I failed over to it.  I made some changes to my primary farm by adding a few announcements to a web part on a site and attached a picture to it.  After some time, I decided to remove mirroring from the primary database.  The reason I removed mirroring instead of doing a fail over, is because I could not have downtime on the primary farm.  Nor did I want to take any chances breaking the database by reversing the mirroring if my technique did not work.

After breaking the mirror, the mirrored database showed as "Restoring.." until I ran the command:  RESTORE DATABASE [SharePoint_Content] WITH RECOVERY.

This method is used to make the mirror available again as a stand-alone database.  Once the database was available, I loaded up my SharePoint site on the fail over farm with my fingers crossed.  As the page loaded, I saw a dreaded "Error 400 - Bad Request."  I figured this would happen, as things are rarely straightforward with SharePoint. I didn't have time to address the issue so I decided to just restore from my most recent backup and put my experiment on hold.  After issuing a restore command using stsadm, I saw a peculiar error which stated that it could not restore my site because no content databases were associated and suggested that I add a content database before proceeding.

Perhaps this could work after all! I loaded up the administration panel, found at https://servername:8080, and navigated to Content Databases under Application Management.  The Sharepoint_Content database was listed as it should have been but I figured since it was not working as desired anyway, I could remove the SharePoint_Content database from the configurations and re-add it.  First, I removed the content database and re-added a new content database with the same name and selected my SQL Server from the drop-down menu.  I clicked OK and SharePoint updated its configuration.  Soon the new content database was listed.

I hurried back to my site, refreshed the browser and to my delight, the page loaded and the announcements I had added in Las Vegas were displayed on the site running in San Diego. It was at this moment when I realized that this instance of making the impossible possible would be perfect fodder for my first blog post on netnerds.net.