Clustering Concepts for the Common Man

Jen McCown, 2013-01-29

SQL Server clusters are widely used, and widely misunderstood, which makes people like our good friend (and clustering MVP) Allan Hirt cry bitter tears. So here are a few notes for you and yours.

Cluster IS NOT Disaster Recovery

A cluster does not protect against disaster. Unless it’s a very, very, very limited scope disaster (that scope being, the hardware of the one server running SQL, not including the disks). A cluster is considered a High Availability solution.

Why: A typical cluster lives in a single physical area (typically, the server room). And, a cluster shares disks. Anything that goes wrong with the SAN, the power, the building, or the network, goes wrong for the ENTIRE cluster.

Failover IS NOT Ultimate Solution

Failing over the cluster should not be your first reaction to any given problem. Letting your DBA troubleshoot the issue should be the first reaction.

Why:  If there’s a problem, you need to know the source of the problem, so that it doesn’t happen again. Not to mention, restarting the service and/or failing over the cluster can exacerbate the problem AND wipe out important troubleshooting data. It’s lose-lose!

Failover IS NOT A Freebie

A failover is (potentially) quicker than a restart of a single server, sure. But you still lose all your connections, all open transactions are rolled back (and not automatically restarted), and you still have to wait for the SQL Server service to spin up.

Why: SQL Server itself doesn’t know the difference between failing over, and simply being restarted on a single instance. It’s the same thing, in SQL’s eyes.

Second Node IS NOT Magical

This one is a two-fer.  First, understand that if your secondary node isn’t functional for whatever reason, you don’t actually have a failover cluster. Plenty of shops ignore issues on their secondary node for years, just assuming that they’ll never need it.

Second, moving the services and disks over to the second node rarely gets you anything that a service restart wouldn’t.  That second node isn’t magically immune to deadlocks, long transactions, nor memory and disk pressure. Even in cases where SQL Server isn’t responding, or is deeply broken in some way, a service or server restart is at least as good as a failover.

Why Do We Even Have This Cluster?

I don’t know. Maybe someone high up fell in love with the word “cluster”, the way they’re falling in love with “The Cloud” right now. Maybe you have a legitimate need for, say, rolling upgrades with minimal downtime.

Regardless, you have it. Understand the concepts, and understand the few cases in which failing over is actually beneficial. Here, have an Introduction to Clusters, with diagrams. Need more? Check out Allan’s 4-day training classes.

Happy days,

Jen McCown

P.S. I’m on a boat this week, and so I’ll be out of touch for a while. The out-of-touchness includes our awesome DBAs@Midnight webshow, which next airs on  February 8 at 11pm Central Time. Catch up on back episodes at

P.P.S  More resources, from SQL Server BOL:

Share on TwitterShare on LinkedInShare on TumblrSubmit to StumbleUponSave on DeliciousDigg ThisSubmit to reddit





Related content

Database Mirroring FAQ: Can a 2008 SQL instance be used as the witness for a 2005 database mirroring setup?

Question: Can a 2008 SQL instance be used as the witness for a 2005 database mirroring setup? This question was sent to me via email. My reply follows. Can a 2008 SQL instance be used as the witness for a 2005 database mirroring setup? Databases to be mirrored are currently running on 2005 SQL instances but will be upgraded to 2008 SQL in the near future.

Robert Davis


1,567 reads

Networking – Part 4

You may want to read Part 1 , Part 2 , and Part 3 before continuing. This time around I’d like to talk about social networking. We’ll start with social networking. Facebook, MySpace, and Twitter are all good examples of using technology to let…

Andy Warren


1,530 reads

Speaking at Community Events – More Thoughts

Last week I posted Speaking at Community Events – Time to Raise the Bar?, a first cut at talking about to what degree we should require experience for speakers at events like SQLSaturday as well as when it might be appropriate to add additional focus/limitations on the presentations that are accepted. I’ve got a few more thoughts on the topic this week, and I look forward to your comments.

Andy Warren


360 reads