High availability solutions bakostech

BakosTech Analysis, Collaboration and support

High Availability Solutions Presented byViktoria Bakos

Linkedin http://www.linkedin.com/pub/viktoria-bakos/4/830/363

High availability solutions, architecture and comparison SQL Server 2012

High level summary

Database Mirroring

Fail over clustering

Transactional ReplicationLog Shipping

Always on

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.

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.

Transactional Replication

load balancing option.

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.

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.

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)

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

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

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