This document provides an overview and comparison of several high availability solutions in SQL Server 2012 including database mirroring, failover clustering, transactional replication, log shipping, and AlwaysOn availability groups. Database mirroring provides redundancy using log transfer but requires separate instances, while failover clustering uses a virtual service name across nodes but requires shared storage. Transactional replication supports load balancing across multiple subscribers. Log shipping and database mirroring both rely on log backups and restores but log shipping allows read access during restore. AlwaysOn maximizes availability across databases in an availability group using Windows clustering without shared disks.

1. BakosTech
Analysis, Collaboration and support
High Availability Solutions
Presented by
Viktoria Bakos
Linkedin
http://www.linkedin.com/pub/viktoria-bakos/4/830/363

2. High availability solutions, architecture and comparison
SQL Server 2012
High level summary
Database Mirroring
Fail over clustering
Transactional Replication
Log Shipping
Always on

3. Database Mirroring
Provides redundancy using log-transfer mechanism. Log records are sent to the
mirror transaction log as soon as the log buffer is written to the disk on the
principal db. Can be configured either high safety or high performance. Things
to understand for performance reasons: log-generation rate, 3 of concurrent
connections, size of transactions, network bandwidth. You want high
bandwidth, low-latency network for reliability.

4. Fail over clustering
Cluster includes two or more physical servers (nodes) with identical configuration.
It improves physical server hardware availability excuding shared storage. It
can also improve maintenance downtime. (failover seconds to few minutes).
Shared storage is a single point of failover. Not solution for load balancing.
Clustering requires Enterprise or data center versions of OS and SQL Server
Standard, Enterprise or BI editions. Form SQL Server 2008R2 it can be
geoclusters.(storage - synchronize disk arrays across geodistances). With SQl
Server 2012 you now have multi-site clustering across subnets. Client
application should have reconnect logic to be cluster aware.

5. Transactional Replication
load balancing option.

6. Log Shipping
Business continuity option where the database transaction log from one sql server
is backed up and restored onto a secondary SQL Server and deployed for
high-availability such as warm standby, reporting or disaster recovery
purposes. The two SQL Servers have to share connectivity that enables the
secondary to copy the transaction log and restore it. It uses the transaction log
backup, operating system copy file and transaction log restore. You need to
redirect users to a standby server vs clustering. Log shipping does not require
a shared disk system vs clustering. Log shipping requires separate systems
and no shared disk. Log shipping fail over is always a manual process
although you can automate it. Log shipping is done per database.

7. Always on
New to SQL Server 2012. Maximize availability for one to many databases as a
group by configuring availability groups. It uses Windows Fail over cluster and
SQL server name/ip address. Availability replicas posses a non shared copy of
each of the databases in the availability group where data can be maintained
asynchronously or synchronously. Primary replicas are available for users for
read-write access. Secondary replicas maintain fai lover copy of each
database and can also be read-only access.

8. Difference between Mirroring and
clustering
Mirroring provides protecting at the database level clustering provides protection
at the instance level
Database mirroring does not require shared storage hardware and does not have
a single failure point with shared storage.
In database mirroring the principal and mirror servers are separate SQL Server
instances with distinct names vs clustering one virtual service name and ip
address remains the same no matter which node the cluster is hosted on.
cluster fail over is longer than the timeout value on database mirroring - so a
mirroring session will reach to a cluster failover as a failure of the principal
server if mirroring is configured on is configured within a cluster. (increase the
database timeout value to mitigate this)

9. Difference between Mirroring and
transactional replication
database mirroring and transactional replication are both reading the transaction
log on the originating server but synchronization mechanism is different
Database mirroring directly initiates IO to the transaction log file to transfer log
records.
Transactional replication can be used with more than one subscriber and
database mirroring is a one-db-to-one db solution
You cannot read data on the mirrored database (unless you create a database
snapshot- but that's static point in time)) but you can do near real time reads
on the subscriber db

10. Mirroring vs log shipping
-Both rely on moving the transaction log and restoring it.
-In database mirroring, the mirror db is always in recovery state hence you cannot
query it but in log shipping the database is in standby mode so you can query
the database (if log is not being restored)
-Database mirroring supports only full database recovery while log shipping
supports bulk logged recovery model
-if application relies on several databases then log shipping might be better option
-Mirroring and log shipping can be used together

11. Database mirroring vs Availability
groups
-Both rely on moving the transaction log records and restoring it
Always on has additional availabilities to database mirroring:
-Always on relies on Windows fail over clustering for virtual IP/name (for client
connection) but unlike clustering only uses non shared disks like database
mirroring
-Always on implements availability groups that contain one-many databases to be
failed over as a single group while db mirroring is single database
-Always on supports up to five fail over partners (synchronous/asynchronous
modes) and db mirroring supports only two partners
-Always on supports read-only replica databases kept in sync that can be used for
reporting or database backup while database mirroring only accessible via
database snapshot