TECHNET LIVE MEETING

High Availability Solutions in SQL Server 2012Pieter Vanhove

WHO AM I

• Pieter Vanhove• SQL Server Database Consultant at Kohera• MCTS, MCITP Database Administrator 2008• Love to work with SQL HA/DR solutions• E-mail: pieter.vanhove@kohera.be• Twitter: http://twitter.com/#!/Pieter_Vanhove• Blog: http://blogs.sqlug.be/pieter/• MEET: http://www.microsoft.com/belux/meet/#

Pieter+Vanhove

AGENDA

• What is High Availability• Planned vs. Unplanned downtime• Degraded Availability• Recovery Objectives• Justifying Opportunity Costs

• SQL Server AlwaysOn• AlwaysOn Failover Cluster Instance• AlwaysOn Availability Group

• Database Mirroring• Log Shipping• Compare the different solutions

PLANNED VS UNPLANNED DOWNTIME

• Planned maintenance. • A time window is preannounced and coordinated for planned maintenance

o Software patchingo Hardware upgradeso Password updateso Offline re-indexingo Data loadingo Rehearsal of disaster recovery procedures

• Unplanned outage• System-level, infrastructure, or process failures may occur that are

unplanned or uncontrollable• A robust high availability solution

o Detects these types of failureso Automatically recovers from the outageo Reestablishes fault tolerance.

DEGRADED AVAILABILITY

• Read-only and deferred operation

• Data latency and application responsiveness

• Partial, transient, or impending failures

RECOVERY OBJECTIVES

• Recovery Time Objective (RTO) • This is the duration of the outage. The primary goal is to restore full

service to the point that new transactions can take place

• Recovery Point Objective (RPO)• A measure of acceptable data loss • It is the time gap or latency between the last committed data

transaction before the failure and the most recent data recovered after the failure

JUSTIFYING OPPORTUNITY COSTS

• Avoiding downtime• Outage recovery costs are avoided all together if an outage doesn’t occur in

the first place • Investments include

o The cost of fault-tolerant and redundant hardware or infrastructureo Distributing workloads across isolated points of failureo Planned downtime for preventive maintenance

• Automating recovery• If a system failure occurs, you can greatly mitigate the impact of downtime on

the customer experience through automatic and transparent recovery

• Resource utilization • Secondary or standby infrastructure can sit idle, awaiting an outage • It can be leveraged for read-only workloads• To improve overall system performance by distributing workloads across all

available hardware

ALWAYSON FAILOVER CLUSTER

WHAT IS FAILOVERCLUSTER INSTANCE

Public Network

Storage

Server A (Active)

Client PCs

Server B (Passive)

Storage

San Mirroring

Shared Storage

Virtual Windows Server

Virtual SQL Server Instance

WHAT IS A FAILOVER

Public Network

Server A

Client PCs

Server B

Shared Storage

Virtual Windows Server

Virtual SQL Server Instance

Switch storage manually

DNS change Attach/Detach

databases Recreation jobs

Active PassivePassive

CLUSTER TYPE: ACTIVE/PASSIVE

Public Network

Server A

Client PCs

Server B

Shared Storage

Virtual Windows Server

Virtual SQL Server InstanceActive Passive

CLUSTER TYPE ACTIVE/ACTIVE

Public Network

Server A

Client PCs

Server B

Shared Storage

Virtual Windows Server

Active Active

CLUSTER TYPE: ACTIVE/ACTIVE N + 1Public Network

Server A Server B

Shared Storage

Active Active

Server C Passive

BENEFITS OF FAILOVER CLUSTER INSTANCE

• Protection at the instance level through redundancy

• Automatic failover in the event of a failure

• Support for a broad array of storage solutions

• Disaster recovery solution using a multi-subnet FCI

• Zero reconfiguration of applications and clients during failovers

ALWAYSON AVAILABILITY GROUPS

WHAT ARE ALWAYSON AVAILABILITY GROUPS

• HA and DR solution that provides an alternative to database mirroring

• A container for a discrete set of user databases that fail over together

• Multiple possible failover targets

• Secondary replicas support read-only accessAn availability group fails over at the level of an availability replica. Failovers are not caused by database issues

TERMS AND DEFINITIONS

• Primary database • The read-write copy of an availability database

• Secondary database • A read-only copy of an availability database

• Primary replica • The availability replica that makes the primary databases available for read-write

connections • Sends transaction log records for each primary database to every secondary replica

• Secondary replica • An availability replica that maintains a secondary copy of each availability database• Serves as a potential failover targets for the availability group

• Availability group listener • A server name to which clients can connect in order to access a database in a

primary or secondary replica of an AlwaysOn availability group

SYNCHRONOUS COMMIT MODE

1 Commit

2 Write to

Local Log

2 Transmit to Replica

4 Write to Remote

Log

7 Acknowledge

3 Committed in Log

Constantly Redoing on Replica

6 Acknowledge

Log DBDB Log

5

ASYNCHRONOUS COMMIT MODE

1 Commit

2 Write to

Local Log

2 Transmit to Replica

5 Write to Remote

Log

4 Acknowledge

3 Committed in Log

Constantly Redoing on Replica

7 Acknowledge

Log DBDB Log

6

Manual Failover Automatic Failover Forced Failover

- DBA issues a manual-failover command

- Primary Secondary

- Synchronous-commit mode

- Replica must be synchronized

- Response to a failure

- Primary Secondary

- Synchronous-commit mode+ failover mode set to “Automatic”

- Replica must be synchronized

- DBA issues a forced-failover command

- Primary Secondary

- Asynchronous-commit mode

- Replica is not synchronized

FAILOVER TYPES

READ-ONLY ACCESS ON SECONDARY

• You can configure read-only access to the availability replica.

• Allows you to offload you read-only workloads from your primary replica

• Optimizes resources on your primary replica for your mission critial workloads

POSSIBLE SETUP

BENEFITS ALWAYSON AVAILABILITY GROUPS

• Supports one primary replica and up to four secondary replicas• Supports Asynchronous-commit mode and Synchronous-

commit mode• Read-Only access to the secondary databases• Performing backup operations on secondary databases• Provide fast application failover• Flexible Failover Policy• Automatic page repair• Supports Encryption and Compression• Provides an integrated set of tools

PREPARATION

• Install WSFC on each machine and create a single WSFC cluster

• Install SQL Server Instances on each machine

• Enable AlwaysOn through SQL Configuration Manager

• (CREATE ENDPOINT on each instance)

DATABASE MIRRORING

DATABASE MIRRORING

TERMS AND DEFINITIONS

• Principal Server• Principal server is the server which clients connect to and perform their

updates to the database

• Mirror Server• Mirror server is performing the same changes on the mirrored database

• Witness server• The witness server monitors the status of the principal and mirror servers• The witness does NOT trigger the failover, just helps provide “quorum”

• Quorum• In the event of one of the principal becoming unavailable, the mirror can

only failover if it can still see the witness, and the witness agrees it cannot see the principal

• If the mirror fails, principal can only continue if it still sees the witness

OPERATING MODES

No Automatic Detection

Manual Failover Uses synchronous

form of mirroring Does not require

Witness Principal

performance is affected by network speed and distance

High Availability

High Protection High Performance

Automatic Detection

Automatic Failover Uses synchronous

form of mirroring Requires Witness Principal

performance is affected by network speed and distance

No Automatic Detection

Manual Failover Uses asynchronous

form of mirroring Does not require

Witness Principal

performance is NOT affected by network speed and distance

SETUP REQUIREMENTS

• Both the principal and mirror servers must have SQL 2005 + installed

• Both the principal and mirror servers must have space to hold the database

• For automatic failover, the witness server also must have SQL Server 2005+ installed

• Witness can be any edition, even SQL Server Express

• The principal database must use the Full recovery model

• The mirror database must be “prepared”

FAILURE DETECTION

• SQL Server• Ping each other once a second• By default if 10 “pings” are missed, then declare a failure

• Outside SQL Server• Operating System• Network errors• IO errors• Process errors

• Failover speed determined by:• Failure type• REDO queue on the mirror

BENEFITS DATABASE MIRRORING

• Increases availability of a database.• High-safety mode with automatic failover, failover quickly brings the standby copy

of the database online (without data loss)

• Increases data protection. • Database mirroring provides complete or almost complete redundancy of the data• Mirroring partner running on SQL Server 2008 Enterprise or later versions

automatically tries to resolve certain types of errors that prevent reading a data page. Automatic Page Repair

• Improves the availability of the production database during upgrades.• To minimize downtime, you can sequentially upgrade the instances of SQL Server• Rolling upgrade

DATABASE MIRRORING DEPRECATED

This feature will be removed in a future version of Microsoft SQL Server. Avoid using this feature in new development work, and plan to modify applications that currently use this feature. Use AlwaysOn Availability Groups instead.

LOG SHIPPING

LOG SHIPPING

TERMS AND DEFINITIONS

• Primary database • The database on the primary server that you want to back up to another

server.

• Secondary database • The warm standby copy of the primary database.

o Restoring stateo Standby state

• Monitor server• When the transaction log on the primary database was last backed up.• When the secondary servers last copied and restored the backup files.• Information about any backup failure alerts.

TERMS AND DEFINITIONS

• Backup job • Performs the backup operation• Logs history to the local server and the monitor server• Deletes old backup files and history information

• Copy job • Copies the backup files from the primary server to a configurable destination on

the secondary server• Logs history on the secondary server and the monitor server.

• Restore job • Restores the copied backup files to the secondary databases. • Logs history on the local server and the monitor server• Deletes old files and old history information.

• Alert job • Raises alerts for primary and secondary databases when a backup or restore

operation does not complete successfully within a specified threshold.

LOG SHIPPING CONCEPT

Primary DatabaseServer

Secondary DatabaseServer

Backup JobRestore Job

Log shipping Log shipping

Monitor DatabaseServer

Backup Share

FAIL OVER TO A LOG SHIPPING SECONDARY

1. Copy any uncopied backup files from the backup share to the copy destination folder of each secondary server.

2. Apply any unapplied transaction log backups in sequence to each secondary database.

3. If the primary database is accessible, back up the active transaction log and apply the log backup to the secondary databases.

4. After the secondary servers are synchronized, you can fail over to whichever one you prefer by recovering its secondary database and redirecting clients to that server instance. Recovering puts the database into a consistent state and brings it online.

COMPARE SOLUTIONS

COMPARING FAILOVER

Failover clustering

• SQL Server Instance

• Automated• Within

minutes• No

application redirection required

Availability Groups

• Database Group

• Manual or automated

• Few seconds to minutes

• No Application redirection required

Database Mirroring

• Database• Manual or

automated• Few seconds

to minutes• Application

redirection required (can be automated)

Log Shipping

• Database• Manual• Based on

configuration

• Forced application redirection required

COMPARING SECONDARY SERVER

Failover clustering

• Instance• Multiple

nodes• Server in

same LAN• Hot standby

server• Available for

use• Shared

storage• Status check

using Heartbeat

Availability Groups

• Database• Up to 4

Secondary Replica’s

• Span across WAN

• Hot standby• Available for

use• Storage need

not be shared• Status check

WFC

Database Mirroring

• Database• Principal and

Mirror• Span across

WAN• Hot standby• Not available

for use• Storage need

not be shared• No status

check unless using witness

Log Shipping

• Database• Multiple

secondary nodes

• Span across WAN

• Warm standby

• Available for use

• Storage need not be shared

• No status checking

COMPARING DATA CONSIDERATIONS

Failover clustering

• All instance databases are shared

• Loss limited to last hardened record

• No data copy across network

Availability Groups

• Configured database is mirrored or readable

• Loss limited to last mirrored transaction

• Synchronous or Asynchronous commit mode

Database Mirroring

• Configured database is mirrored

• Loss limited to last mirrored transaction

• Synchronous or Asynchronous mirroring

Log Shipping

• Configured database logs are applied

• Loss limited to last applied transaction log backup

• Transaction log Backup, Copy and Restore

COMPARING NETWORK CONSIDERATIONS

Failover clustering

• Network connectivity needs to meet heartbeat requirements

• Data is not transferred over network

Availability Groups

• Network latency to meet I/U/D SLA’s

• Data is transferred over network

Database Mirroring

• Network latency to meet I/U/D SLA’s

• Data is transferred over network

Log Shipping

• Network latency to meet RTO

• Transaction Log file records transferred over network

WRAP UP

• What is High Availability• Planned vs. Unplanned downtime• Degraded Availability• Recovery Objectives• Justifying Opportunity Costs

• SQL Server AlwaysOn• AlwaysOn Failover Cluster Instance• AlwaysOn Availability Group

• Database Mirroring• Log Shipping• Compare the different solutions

RESOURCES

• AlwaysOn Team Blog• http://blogs.msdn.com/b/sqlalwayson/

• SQL Server 2012 Whitepapers• http://msdn.microsoft.com/en-us/library/hh403491

• MSDN – SQL Server High Availability Solutions• http://

msdn.microsoft.com/en-us/library/ms190202.aspx#RecommendedSolutions

© 2011 Microsoft Corporation. All rights reserved. Microsoft, Windows, Windows Vista and other product names are or may be registered trademarks and/or trademarks in the U.S. and/or other countries.

The information herein is for informational purposes only and represents the current view of Microsoft Corporation as of the date of this presentation. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information provided after

the date of this presentation. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION.