SQL Server Clustering

High availability refers to solutions that are more local in nature and generally
tolerate smaller amounts of data loss and downtime.

Disaster recovery is when a catastrophic event occurs (such as a fire in your data
center), and an extended outage is necessary to get back up and running.
Both need to be accounted for in every one of your implementations.
The key to availability is to calculate how much downtime actually means to the
business. Is it a monetary amount per second/minute/hour/day? Is it lost
productivity? Is it a blown deadline? Is it health or even the possibility of a lost
human life (e.g., in the case of a system located in a hospital)? There is no absolute
right or wrong answer, but knowing how to make an appropriate calculation for your
environment or particular solution is much better than pulling a number out of a hat.
This is especially true when the budget comes into play.
Microsoft ships SQL Server 2008 with five major availability features:
1. Backup and restore
2. Failover clustering
3. Log shipping
4. Database mirroring
5. Replication
Failover Cluster are meant for high-availability that is it helps to maintain client
access to applications and server resources even if you encounter some sort of outage
(natural disaster, software failure, server failure, etc.).
Depending on data center and hardware implementation, a failover cluster can be
implemented within only one location or across a distance. A failover cluster
implemented across a distance is known as a geographically dispersed cluster and
generally provides both disaster recovery as well as high availability.
Log shipping provides protection on a per-database, not a per-instance, level. Its
concept is very simple: take transaction log backups from a database on one SQL
Server and apply them to a copy of the database on another server.
The source SQL Server instance is called the log shipping primary (or just primary),
and the destination SQL Server instance is called the log shipping secondary (or just
secondary). The secondary is also known as the warm standby.
Together, a primary and secondary are known as a log shipping pair. There can be
multiple secondaries for each primary.
If you implement log shipping using the built-in feature of SQL Server 2008, it
utilizes three SQL Server Agent jobs: the transaction log backup job on the primary,
the copy job on the secondary, and the restore job on the secondary.
Combining Failover Clustering and Log Shipping
Combining log shipping with failover clustering is arguably the most common
configuration seen for years, and looks something like the Figure.
Until database mirroring was introduced in SQL Server 2005, it was the favorite solution,
and continues to remain a no-brainer, even though database mirroring is available. The
only caveat to take into account is that if your primary and/or secondary are failover
clustering instances, the locations where transaction log backups are made on the primary
and then copied to and restored from on the secondary must reside on one of the shared
disks associated with their respective instances. Other than that, log shipping should just
workand that is what you want. It is based on technology (backup and restore,
copying files) that is easy to grasp. Theres no magic. One of the reasons that log
shipping is so popular with clustered deployments of SQL Server is that it may also
balance out the
cost of buying the cluster, which can be considerable for some, depending on the
implementation. And why not? You have to back up your databases anyway, and chances
are you have to do transaction log backups, so it is a natural fit.
SQL Server High Availability Technology Comparison
Clustering does NOT provide a standby or a redundant copy of the databases; a

failure in shared storage can be a severe problem. Yes, there are hardware
redundancies at some SANs, but they dont come for cheap so you need another way
to duplicate your data.
Log shipping allow to create a standby database that can be even readable for
reporting purposes. However, it has some disadvantages(no automatic failover, data
loss could happen because logs are shipped on a schedule, and more space was
needed for the log backups).
If no data loss can be tolerated by Log Shipping, then database mirroring should be
used. Both LS or DB mirroring can work smoothly with clustering since the virtual
name of the clustered instance will be the end point.
However, DB mirroring or Log Shipping protects only against one single database. If
the primary server fails, work needs to be done to bring a second server online.

SQL Server Clustering

Uploaded by

SQL Server Clustering

Uploaded by

High availability refers to solutions that are more local in nature and generally

tolerate smaller amounts of data loss and downtime.

SQL Server High Availability Technology Comparison

Clustering does NOT provide a standby or a redundant copy of the databases; a

You might also like