Data Management

High Availability with SQL Server and Double-Take


I have been doing a lot of work with SQL Server and Disaster Recovery. Many of my clients are particularly fond of Double-Take. In this three part blog series, I will go over the fundamentals of configuring Double-Take.

Note: All screen shots are located a the bottom of the blog; simply hover your mouse over the screen shot to see what Figure it is. -Steven S. Warren

In the age of catastrophes, which include disk failures, power failures, fires and floods, disasters can take their toll on any business and stop the flow of information. With each minute of lost data translating into unrecoverable revenues, downtime is being taken seriously. As a DBA today in the IT field, we are in an age of zero downtime if possible. To make this dream come true, NSI's Double-Take software provides high availability for Windows 2000/2003/2008 machines running SQL Server 2000/2005. The software allows a secondary SQL Server to take over the identity of the failed SQL Server while suffering no disruption or data loss. In this article we will discuss how to install and configure Double-Take for replication and mirroring.

How does it Work?

Double-Take software gives you the ability to configure a Source and Target machine and choose the directories and folders that you want to replicate from Source to Target. Double-Take uses a delta-replication strategy which only sends the changes since the prior replica. This provides a real-time fast replication of data from one server to the other minimizing the bandwidth. This is a very popular model for pushing data over a WAN.

Lab Environment

In order to successfully show you how to implement this strategy, you will need the following:

  • 2 Windows 2000/2003 servers
  • 2 copies of SQL Server 2000
  • 2 copies of Double-Take

I created my lab using VMWARE Workstation; this is a great piece of software for running multiple environments on one machine or server. First, I configured basic Windows 2003 Server installations followed by the installation of SQL Server 2000 (w/ SP3A or SP4) and finally Double-Take. You can install Double-Take by just accepting the installation defaults.

Configuring Double-Take on the Source Server

The only initial configuration on the Source server is to install the Operating System (OS), SQL Server 2000 with Service Pack 3A or SP4 and finally load Double-Take.

Configuring Double-Take on the Target Server

After the installation of Double-Take is complete, click Start | Administrative Tools, Services and choose the Double-Take service as shown in Figure A. Next, click the Log On folder and select Allow service to interact with desktop.

Click OK and shut down the following services on your target server:

  • MSSQLSERVER
  • SQLSERVERAGENT
  • Message Queuing (If installed)
  • Distributed Transaction Coordinator (DTC)

Once you have shut down these services, you will also need to set them to a manual status. Now that we have configured both the Source and Target, let's move on to configuring Replication and Mirroring.

Configuring Replication and Mirroring

Let's begin by clicking Start | Double-Take | Management console as shown in Figure B. Next, Double-Click your Source machine to logon (Figure C). In this lab, Belle is the Source server. Our next step is to right-click on the Source machine and choose Properties. Then, choose the Setup tab and deselect Perform Remirror After Auto-Reconnect (Figure D). If you do not deselect this, the source server could overwrite the target after a failback. We are now ready to create our replication set that will mirror and replicate to our Target server. In order to perform this, right-click on your Source machine and choose New Replication Set and enter the name of the replication set as shown in Figure E.

Next, choose the following directories you would like to replicate onto the Target machine. For SQL Server, I chose the following: Data and Log files (Figure F.)

Note: Do not forget to right-click on the replication set name and choose save.

Next, drag and drop your replication set onto the Target machine (Beast) as shown in Figure G. As you can see the Source Server, Replication Set, Target Server and IP address are automatically configured. I recommend that you just review the screen to make sure that you did not make any mistakes. When your review is complete, remember to click connect to start the mirror and replication process (Figure H.)

Finally, you can test mirroring and replication by creating new databases, tables, indexes, etc on the Source server and seeing it appear almost instantly on the Target server. In my next blog we will build upon what we have learned here by showing you how to configure a failover/failback to the Target/Source SQL Server automatically. We will also show you what to do in order to restore the SQL Server data on the Source machine to bring the server back online.

Figure a

Figure b

Figure c.

Figure d.

Figure e.

Figure f.

Figure g.

Figure h.

8 comments
heeyoon
heeyoon

Our mission critical servers do not belong to the Active Directory domain. Will this replication with Double-Take work between two Windows 2003 Standard and/or Enterprise servers without domain account? What about the compability between SQL2000 and SQL2005? Thanks,

The3Seat
The3Seat

Good article Steve. I'm glad that you showed the flexibility of our product. You should also try Double-Take Application Manager which is a wizard-like interface included with Double-Take and hides most of these SQL Server implementation and management details behind a couple of buttons. It also makes sure that your environment, servers and SQL Server/Exchange/SharePoint/etc. are configured correctly with pre-flight checks based on best practices. You should also check out our Full Server Fail-over features that work great for applications like SharePoint and IIS by recovering the entire system, Data, Apps, OS, Registry, etc. Despite hardware and driver differences. Nicholas Schoonover Senior Solutions Architect Double-Take Software

robert
robert

I've been using double take for a while now but the databases on my target server are constantly being marked suspect. Is there a best practice for using double take with SQL Server ? A quick overview of how we us it is as follows We let it replicate changes through out the day and after the source db has been backed up we stop the source sql server followed by double take. We start sql server on both the source and target to run a reconiliation report then we stop sql server on the target and restart double take. Should double take be able to cope with such a scenario ?

murad_77
murad_77

I have 2 servers one from Dell PE 2850 and other is Intel server. On both servers Window 2003 server R2 is installed. Dell Server is Primary Domain Controller and Intell server is Additional Domain Controller. i have installed Double Take ( Eval ) Software on both , but my configuration seems to incomplete due to following anamlies 1.when failure occures target accquire IP address but not name of source Server. 2.when source server is online then IP conflict Error is popuped on Target. 3. when failure occurs then I have to manually interven by pressing OK button , so is it possible as soon as source server fails it get source identity AUTOMATICALLY to get rid of Pressing OK Button 4. when source server is back on-line then i have to PRERSS FAILBACK Button, kindly tell me how this FAIL Back can be automated. 5. Also when failure/failback Occurs then Replication does not work by giving message that After Failure Restoration is not being made. Kindly answer me above questions and Also guide me that how can i implement best replication and Failover starategy . I wana to replicate E drive of source server.on source server my client is running Applications Developed in Labview and Visual studio.But Aplication Manager of Double Take provide facility for SQL server and Exchange server. Kindly send me scripts requied for Activ Directory environments, Pre/Post FAILOVER , Pre / Post FAIL BACK . My client main moto is if Primary Domain Controller Fails then Additional DC should Seamlessly (no Manual Intervention ) replace it . Sir i am evaluating this product for my client ,any help in this regard eg presentation,Webcast,lectures, guide etc will be highly appretiated. kindly send me soon response Regards

femiaudu
femiaudu

I have databases s suspect after running a full server recovery option . All other files including OS are fine apart from 2 databases in SQL.CAn you itemize the preferred steps to test a failover that involves SQL databases?

schmed
schmed

We are having the same exact scenario with large databases (250GB+), twice already during DR exercises the databases have been marked suspect, DT tech support states 8196 (The maximum amount of memory for replication queuing has been reached. Replication is stopped and memory is being freed.) is the cause, I say "Nuts!".

The3Seat
The3Seat

Double-Take specifically protects against suspect databases with patented data integrity algorithms that have been proven for well over a decade in tens of thousands of SQL Server implmentations. So when I hear this type of issue then I have to believe that you configured something wrong. Tag the MDF and LDF files. I usually grab the entire instance and de-select the TempDB files. That's the most basic implementation, you also have to wait until the baseline mirror says "Idle" before the data is fully synchronized and you can test. From that point forward Double-Take only sends the transaction aware changes to the database and transaction log files. You also have the option of using the Double-Take Application Manager which is included in the purchase price and will analyze your systems for the most common SQL configuration problems and help you to correct them. Then you can use it to easily manage the entire implementation. You can also log into our support web site and get access to the Double-Take Application Notes for SQL and it lists all of the implementation details under the hood if you choose to do it yourself without DTAM. Nicholas Schoonover Senior Solutions Architect Double-Take Software.

Steven Warren
Steven Warren

Your target database should be in a read-only state. I suspect that it is going suspect b/c all changes arent written to it or you are failing over improperly.

Editor's Picks