SQL Server Database Mirroring vs. Double-Take

Email This Page | Print This Page | Go Back

(4 votes, average: 3.25 out of 5)

Loading ...

We regularly get questions about what is the best way to replicate or mirror SQL Server databases to protect against disaster and to provide high availability. There are many options out there and there is no right answer, but I thought I would address 2 we have used (SQL Server Database Mirroring and Double-Take) and provide some input as to what we’ve found.

SQL Server 2005/2008 Database Mirroring: (Recommended)

Overview: This works by having SQL Server write each transaction to both SQL Server databases at the same time on 2 different servers so that they are synchronized. Depending on the mode you choose, the transactions are committed either synchronously or asynchronously.

Pros: The advantage of this option is that it is a standard feature of SQL Server and its free. It has 3 modes for those that desire performance and those that must have reliability. The 1st mode is the synchronous mode with automatic failover (High availability and Reliability), the 2nd mode is asynchronous without automatic failover (High Performance) and the 3rd mode is synchronous without automatic failover (High Reliability). The 1st mode requires a witness server to establish a quorum in order for the SQL Servers to know who is the primary and who is the secondary. A nice thing about this mirroring solution, and something we appreciate, is the simple user interface. It is so simple that even a novice IT person should be able to figure it out.

Cons: The mirroring is on a database by database basis so it is possible that you have the primary and secondary for a group of databases spread across the 2 SQL Servers. This is not much of a problem if you have 2 reliable servers equally paired and you can always fail over the individual databases as needed if you prefer them to be in sync on the same server.

Configuration Point: Depending on your needs, it is in my opinion, to configure SQL Server Database Mirroring in either the 1st or 3rd mode depending if you want automatic failover or not. We have seen issues with database corruption with the 2nd option, but the 1st and 3rd options prevent this. In our situation we prefer the 1st mode because we desire immediate failover and our software is written using ADO which is designed to handle failing over if the 1st connection fails. Also, the witness server doesn’t have to be an expensive server since it is just designed to provide a quorum.

Double-Take:

Overview: This is a block level file replication option that works by monitoring the database and log files and replicating any changes in them to the other server. Their marketing material says that the change is at a very low I/O level thereby “almost” guaranteeing no file corruption but if you read the fine print, they can’t guarantee no corruption.

Pros: They are considered an industry standard and have a long track record. If you talk to most IT people and ask them about the company, you’ll hear nothing but glowing remarks. The replication is more than just SQL Databases so you can use the product to replicate regular files too. Also, this is supposedly a great option for replicating over a WAN, but that was not our need.

Cons: Expensive option compared to SQL Server Database Mirroring. We purchased 4 licenses with SQL Server replication and it cost us about $12,000 in the Fall of 2008. The actual price may have varied somewhat but it was pretty close. The configuration was not simple and we had to have 2 DBA’s on the phone with Double-Take tech support for 2 days trying to get our simple configuration working. At the time there was an issue with the 64-bit version but this has been fixed. Also, there wasn’t one program or interface to configure it all and it was confusing. To Double-Take’s defense, the tech support people were available and very helpful. One negative for us, which some would say is a positive, was the switch from Secondary back to Primary was a manual process that took a few steps and required a delay while the Secondary was replicated back to the Primary.

Writer’s Comment: One unfortunate moment happened after running Double-Take for about 1 month. We had a hardware failure on the primary SQL Server and discovered that the Double-Take failed to switch over and therefore, our applications went down. We also discovered that the replication had stopped earlier for some reason and therefore, the database on the secondary server was completely out of sync. Fortunately, we were able to recover the databases from our Primary server’s hard drives and install them on another server. This failure caused us to be down for several hours while we were struggling with it. This incident was both frustrating and scary because after spending $12,000 dollars on a product to protect against a failure, it failed to work itself. Some might say that it was our configuration that was at fault, and while I never want to say it was never our fault, remember that Double-Take helped us configure it over a 2 day period. The end result of this was that we decided to look for another solution.

Configuration Point: We installed the Double-Take on 2 servers being replicated. These servers were Dell 2950’s running 64-bit Server 2008 and SQL Server 2005. The databases being replicated were small and few in number. The average size was less than 1GB and we probably only replicated about 5 databases.

Summary: As I said earlier, there is no right answer. Also, I’m sure Double-Take would disagree with my earlier statements and they are more than willing to disagree but this was our experience. We deal with sensitive information and we lost confidence in Double-Take and have been pleased with SQL Server Database Mirroring (Replication). I’m not saying don’t buy Double-Take because it might be the perfect solution for you, but I’m saying that we had issues and prefer the simple and integrated solution of SQL Server Database Mirroring.

Share Is Caring: