Freigeben über

Failover farms by using SQL Server log shipping: some important reminders

  • Artikel

I have been working lately on a few projects implementing failover farms fro SharePoint 2007. Amazingly, I encountered a few obvious supportability issues while reviewing the the failover process for each of these projects.

The first one, and again it might seem obvious, concerns the configuration database. The failover process documents were just mentioning “log shipping of the databases” without mentioning there are a few databases in a SharePoint farm for whom log shipping is simply not supported. Among these ones, the most obvious one is the configuration database. SO, it looks like this is a quite common assumption that log shipping databases across farms will just exactly duplicate the environments and keep them in sync. This TechNet article is very clear about that: “The configuration database cannot be log shipped to another farm because it contains computer-specific information. You must maintain the same customizations and configuration settings on both farms manually.” Furthermore, site collections you had to your primary farm will not be registered in the configuration database of the secondary farm even though the content databases containing these site collections are log shipped from the primary to the secondary farm.
You have more or less two ways to work it around:

  • Manually detach/attach the content databases in the secondary farm to have the newly created site collections registered in the secondary farm configuration database
  • Perform these operations by means of a so-called “refresh script”, the same TechNet article provides an example of such a script.

When looking in more details about what is stored in the configuration database, one of the major concerns in my opinion is about the Alternate Access Mappings because you cannot backup these ones. You have to manually export the list of AAMs by means of the stsadm -o enumalternatedomains command. Since these AAMs have to exactly matching between the primary and secondary farm, it might become a serious issue in the disaster recovery process if not properly documented.

Well, there are obviously a lot of other concerns expressed in the article (patch level alignment not to mention…), however I was feeling like it would be important to keep in mind that relying on log shipping only will not provide a robust disaster recovery/failover scenario as assumed by some customers I worked with recently. Not only it will not be robust but simply lead to unsupported scenarios.