What Are High Availability (HA) and Disaster Recovery (DR)
The line between High Availability (HA) and Disaster Recovery (DR) can be a little blurred. Typically you might see them defined as follows.
- High Availability (HA) : Keeping the system available at all times. This could be with zero downtime, or near zero downtime.
- Disaster Recovery (DR) : Getting your system back online in the event of a catastrophic failure.
The reason it becomes blurred is because some of the tools available for HA may reduce the likelihood of a DR scenario occurring, and some of the DR tools may be helpful for HA.
The rest of this article will describe some of the features that may be useful for HA and DR. Remember, your worst case scenario is rebuilding everything using your OS and database backups.
Log Shipping
This uses the backup and recovery system to keep a copy of the database relatively up to date. Transaction log backups are shipped to a remote server, where they are applied to the remote database, keeping it up to date. There is some lag involved as the logs have to be backed up, shipped and applied, of if your log backups happen once per hour, you could be an hour out of date on the remote site in a failure scenario.
There is no auto-failover, so you are responsible making sure the remote box is available before having users connect.
Pointing clients to the new box can be problematic if they make direct references. This could be as simple as defining a DNS alias to the server, which you can redirect at will, or using a load balancer in front of the server.
The target database is unavailable during recovery. You could switch it to standby, making the system read-only, but then the logs wouldn’t be applying.
Replication
Once set up, replication has less latency than log shipping as it uses internal mechanisms to replicate the data between servers. Unlike log shipping, the targets are usable, but you are still responsible for getting the clients connected to the correct database.
Mirroring
Mirroring has been replaced by AlwaysOn in later releases.
Mirroring relies on internal mechanisms to ship log information between servers, allowing zero latency and zero data loss. When a change is applied on the primary server, it is also applied to the failover partner, so there is no data loss. This last point is configurable. The mirroring can be synchronous, so you know the transaction has been mirrored before moving on. If it is configured as asynchronous, the performance of the primary will be better, but there is potential loss of data.
Client connections are managed automatically. The connection details include an automatic failover partner, so if a client can’t connect to the primary server, it automatically tries the failover partner.
It’s worth remembering there can only be one failover partner and that partner is unusable until you failover.
Always On and Availability Groups
Always On is the evolution of mirroring. There are some similarities, in that it uses internal mechanisms to keep the databases in sync, can provide zero latency and data loss and has automatic failover and reconnect of clients.
The big differences are:
- The partner servers are usable as read-only clients. That can be useful for reporting.
- You can have multiple partner servers.
- You can group databases into an availability group, so groups of databases will failover simultaneously.
Clustering
Clustering is where two or more servers use the same disks, but only one server can use the disk at any one time. In the event of a server failure on the primary server, the second server will spin up and the database will be running again, because it is using the same disks as the other server. It will effectively look like the primary server has been power cycled. This will protect you from server failures, but any problems with the shared disks will be a problem on both servers. So clustering is protecting the hardware, not the database.
Note. If you are running in a virtual environment, the virtualisation layer is probably protecting you at the server (VM) level, so you may be able to ignore clustering altogether.
You may well find AlwaysOn is more useful from a database perspective than clustering.
For more information see: