Mirror vs. Cluster - Which should we do?

  • There is a low limit to the number of databases which can be mirrored. Below is a direct quote from a response to us my Microsoft Consulting Services:

    "On a 32-bit system, database mirroring can support a maximum of about 10 databases per server instance because of the numbers of worker threads that are consumed by each database mirroring session.

    SQL Server 2008 64-bit has twice as many threads and therefore can support twice as many mirrored databases as 32-bit. As always, Microsoft recommend ensuring this is tested and the architecture is sized accordingly before being moving to production."

  • Here are a couple of documents that will help you understand the issues. Being as the decision already seems to have been made, and the hardware purchased, I would just recommend reading up as much as you can about mirroring and then put adequate performance monitoring in place to help you see any issues before they become show-stoppers.

    http://sqlcat.com/technicalnotes/archive/2010/02/10/mirroring-a-large-number-of-databases-in-a-single-sql-server-instance.aspx

    http://msdn.microsoft.com/en-us/library/ms189901.aspx

  • As a guy who works at a company where mirroring is used, I'm...nervous...about what you are trying to achieve. There's a whole raft of issues to deal with, and I've had the 'pleasure' of dealing with a very diverse range.

    However, one possibility that hasn't been mentioned yet is reducing the number of databases. Depending on your *legal* requirements, having 1 database with a schema for each db may be something to consider. You change rate is low enough (a recent example for me is 2.3 GB synchronized in 10 mins) that I think your major worry is just the number of databases.

    Steve.

  • I have been working with Clustering and DB Mirroring for 4 years now. Some points to consider in setting up mirroring also depend on how much latency is allowed on the Mirror Server. Synchronous mirroring may delay the transaction commits on the Primary since the transaction has to be committed on the Mirror first and then on the Primary. While running bulk inserts, transactions may get delayed.

    Asynchronous Mirroring works well for heavy transaction DBs especially in SQL 2008 where data is compressed before moving to Mirror so its faster. We runs millions of transactions through the week and mirroring (async) works pretty smooth.

    Mirroring is a gift provided by SQL Server and I consider it as advanced technology of Log Shipping.

    My 2 cents ... 🙂

  • I'd be interested in getting a followup to see how their implementation is coming along, especially with the # of databases to be mirrored.

  • Traditional clusters do not provide multisite redundancy, but multisite clusters do provide multisite redundancy. As others have said 130 databases seems like an awful lot to be using Database Mirroring. I would consider a 3-node cluster, with 2-nodes local and then one node in the remote data center.

    I wrote the following article which is a Step-by-Step guide to multisite clusters.

    http://clusteringformeremortals.com/2009/10/07/step-by-step-configuring-a-2-node-multi-site-cluster-on-windows-server-2008-r2-%E2%80%93-part-3/

  • Check out the HA architecture with DB mirroring. The same can be achieved with Clustering as well.

    http://blogs.citrix.com/2011/07/24/mirror-mirror-on-the-wall-whos-the-best-sql-server-of-all/

Viewing 7 posts - 46 through 51 (of 51 total)

You must be logged in to reply to this topic. Login to reply