SQL Clustering or SQL Mirroring

Written by Cornelius J. van Dyk on . Posted in Blog

One of my readers, Steve, posed a good question to me asking which option would be the preferred option between SQL Clustering and SQL Mirroring.

As with all technology decisions, there isn’t any one answer that fits all.  There is only a decision that’s the right decision for any given company with a given culture, given specific constraints at a precise moment in time.  When the culture, technology (hardware or software) or any constraints (like budgets, available skill sets etc.) changes, the original decision may not remain the right decision and the evaluation *should* be recalculated.  I say should because it’s not always practical to revisit technology decisions frequently.  That being said, how often have you posed the question “Why is it being done like this?” and received the answer “Because that’s how we’ve always done it.” or “Because we’ve done it that way for years.”?  Given the fast pace at which technology changes, every major technology decision should be accompanied by a clear timeline for Return on Investment (ROI).  I believe at the end of that timeline, plus 50%, the original decision should be re-evaluated.  If not enough has changed in the equation to warrant an altering of the original decision, then savings continue post ROI.  If however factors have shifted dramatically, then it should be time to re-evaluate.  Change is the only constant…

OK, OK.  I’ll get off my soap box now and reflect, based on my own personal experience, on Steve’s question.  It is a very good question indeed and I’m just going to reflect my abbreviated view here.

  1. Hardware cost.  Clustering has greater hardware cost due to the shared storage requirement of the cluster.  Clustering generally means SAN storage is involved.  If you don’t already have a SAN, or have plans and budget for a SAN, clustering will be an expensive option. 
    Mirror + 1
  2. Idle hardware.  I’ve never met a CFO who liked the idea of having a Extra hardware idle, giving no benefit to the organization, or should I say active benefit.  That’s usually the tunnel vision view of the bean counters.  With Mirroring, the passive node is just waiting for failover and while we as technologists know and understand that in itself, that is an important function, CFOs generally want to see more Active/Active use of their hardware.
    Cluster + 1
  3. Automatic failover.  Yes, both solutions provide automatic failover… sort of.  Clustering is true hardware level failover without requiring applications to do anything because the instance is virtualized.  Mirroring on the other hand requires application code to be using ADO.NET or SQL Native Client in order to do Client Redirect properly and create the automatic failover ability. 
    Cluster + 1
  4. Clustering doesn’t do load balancing or scaling.  You have to manually spread your SQL instances across the cluster nodes in order to load balance.  Peer-to-peer mirroring allows data access from any of the peers, resulting in better scaling. 
    Mirror + 1
  5. Update conflicts.  Mirroring doesn’t resolve update conflicts resulting from multi peer updates mentioned in #4, out of the box.  As a result, the benefit in scaling listed in #4 could be offset by having to deal with update conflicts. 
    Mirror – 1
  6. Expertise required.  Clustering is very complex and most DBAs avoid it if they can.  If you’re going to cluster, you have to have people with the skill set on hand to maintain it.  Mirroring on the other hand is a less complex topic that can be mastered by most DBAs.  Mirror + 1
    Mirror + 1
  7. Assuming per #3 that not all your applications are “Designed for Mirror”, security and update patching can become a problem when you’re running something like a 99.999% uptime SLA.  A cluster backup node can be patched and failover forced to the patched/backup node.  You can then patch the primary node and let the system run on the backup node until the next time patching needs to be done.  At that point in time, the patch process will fail the cluster back over to the primary node. 
    Cluster + 1
  8. Storage redundancy.  A Mirror has redundant storage.  A Cluster has shared storage.  True, SAN technology will have RAID redundancy built in, but at least a RAID5 redundancy design is used in all data storage, so it stands to reason that all members of a Mirror will have some form of redundancy anyway.  The question is how far apart your mirror members are.  It’s not likely that a Cluster will survive a complete Datacenter loss, but a Mirror with an off site member could. 
    Mirror + 1

As you can see, there are many pros and cons to each solution and what is the right solution for you, will depend on your given factors in the equation.

If you can afford both the hardware and the technical expertise involved in doing clustering, then it has been the tried and true method to use.  True, mirroring is making inroads on this title, but most DBAs will still opt for clustering if given the choice. From personal experience, I’ve encountered less problems with *PROPERLY* run SQL Clusters than with Mirrors.



Tags: , ,

Trackback from your site.

Cornelius J. van Dyk

Born and raised in South Africa during the 70's I got my start in computers when a game on my Sinclair ZX Spectrum crashed, revealing it's BASIC source code. The ZX had a whopping 48K of memory which was considered to be a lot in the Commodore Vic20 era, but more importantly, it had BASIC built into the soft touch keyboard. Teaching myself to program, I coded my first commercial program at age 15.

After graduating high school at 17, I joined the South African Air Force, graduating the Academy and becoming a Pilot with the rank of First Lieutenant by age 20. After serving my country for six years, I made my way back into computer software.

Continuing my education, I graduated Suma Cum Laude from the Computer Training Institute before joining First National Bank where my work won the Smithsonian Award for Technological Innovation in the field of Banking and Insurance. Soon I met Will Coleman from Amdahl SA, who introduced me to a little known programming language named Huron/ObjectStar. As fate would have it, this unknown language and Y2K brought me to the USA in 1998.

I got involved with SharePoint after playing around with the Beta for SharePoint Portal Server 2003. Leaving my career at Rexnord to become a consultant in 2004, I was first awarded the Microsoft Most Valuable Professional Award for SharePoint in 2005, becoming only the 9th MVP for WSS at the time. I fulfilled a life long dream by pledging allegiance to the Flag as a US citizen in 2006. I met the love of my life and became a private consultant in 2008. I was honored to receive my ninth MVP award for SharePoint Server in 2013.

Leave a comment

You must be logged in to post a comment.