14

This isn't a how-should-I-do-this question, just to set the stage. It's a what has your experience been? Please read through the whole question before quickly replying.

I spent the day yesterday teaching the current round of SharePoint MCM (Microsoft Certified Masters - see here) students all about high-availability technologies in SQL Server, plus how the SQL log/recovery/backup/restore work. This is really important as under every Enterprise-class MOSS installation is an Entreprise-class SQL Server hidden away, usually without a DBA. Kimberly teaches them a day of database maintenance on Friday (a kind of narrowed down version of the first week of the SQL MCM which we teach).

We were discussing the possibilities around using database mirroring to provide high-availability to SharePoint databases, and the relative pros and cons. Now, I know database mirroring to it's lowest internal depths, as I used to own it while at Microsoft, so no need to point out behaviors and idiosyncracies in your replies. I also know the various caveats and guidelines in the mirroring whitepaper from the SharePoint folks, and yes, they are just generalized guidelines not hard-and-fast rules.

My question is this: I'd like to hear from anyone who's implemented database mirroring for SharePoint and whether you found it worked for you, or you crashed and burned. In particular, how did you find the failover behavior worked for you? Did you end up with some database principals on one server and some on the other, effectively splitting your farm and making it unusable until manual intervention failed everything over to one server? Did you use it for local or remote HA? And so on.

Any replies will be gratefully received and will help broaden the knowledge base around marrying these two technologies, and I'll feed stories back into the SharePoint product group, and the future MCM rotations I teach as well.

Thanks!

[Edit: PS I'll put together a blog post about experiences and guidelines to this over the weekend too]

Paul Randal
  • 7,184
  • 1
  • 35
  • 45
  • >>Did you end up with some database principals on one server and some on the other, effectively splitting your farm and making it unusable until manual intervention failed everything over to one server? Seems like this would be a big issue - you'd need to script the rest to fail on the failure of one. We may be doing this in the future, so I can't answer yet. – Sam Jun 04 '09 at 20:58
  • Indeed, but it's very hard to script it out and cope with every case (like a failed failover - what do you do then?) – Paul Randal Jun 04 '09 at 21:13

3 Answers3

1

We told NOT to even try it with SharePoint by MS (this was 1.5 years ago when we first started planning our SharePoint 2007 implementation).

Jeff
  • 1,008
  • 1
  • 10
  • 14
1

We ended up using a product called Neverfail to add HA our MOSS implementation. It provides a continuous replication of both the SQL server and the MOSS server. Far more reliable with the both the fail over and the fail back scenarios.

Codejnki
  • 66
  • 3
0

No response, check pulse!?

Wow, Paul, have you tried this one on http://www.sharepointoverflow.com yet?

I've worked with clients implementing clustering but never mirroring in production. A colleague of mine has demonstrated to me a POC of the Whitepaper technique for failover, so I've seen it work in person, however, most of the attendees at that presentation were surprised at the technique and not sure about suggesting it to their clients.

Tom Resing
  • 199
  • 2
  • 9