High Availability & Disaster Recovery with SQL Server AlwaysOn Availability Groups

Turgay SahtiyanMicrosoft – Senior SQL Server PFE

www.turgaysahtiyan.com

@ @turgaysahtiyan

Turgay Sahtiyan

Istanbul, TurkeyMicrosoft GBS Team - Senior SQL Server PFE

+12 years IT experience / Last 8 years SQL ServerKey areas : HA&DR Solutions, Performance Tuning, PDW

Community GeekFounder and Former President of SQLPass Turkey ChapterFormer SQL Server MVPSpeaker / Writer / Presenter at Microsoft & SQLSaturdays & Local User Groups

Social MediaTwitter : @turgaysahtiyanBlog : www.turgaysahtiyan.comLinkedin : http://aka.ms/turgaysahtiyan_li

2

Agenda

HA&DR Solutions Before SQL Server AlwaysOn AGsLimitations of Current HA/DR Solutions

SQL Server AlwaysOn Availability GroupsClient Failover using Virtual Network NameReadable Secondary – ReadOnly RoutingBackup on Secondary Replicas

Availability Group ScenariosComparison of SQL Server HA&DR SolutionsReal-Life Customer ScenarioWhat’s Coming with SQL Server 2014

3

SQL Server High Availability

HA&DR solutions before SQL Server 2012 AlwaysOnDatabase MirroringFailover Cluster InstanceLog Shipping

These features help the customer to reach enough HA&DR but..

Customers demand moreBetter AvailabilityHigher ROISimplicity

4

Failover Cluster

5

Public

Shared Storage

SQL Server Instance

SQL Server Instance

Instance level redundancyLocal or Remote SitePresents VNNAutomatic FailoverDoes not protect against data loss

Database Mirroring

6

Principal Database

Client

Principal Server Mirror Server

Mirror Database

Transaction Log Stream

Witness Server

Provide “a” redundant copy of databaseLocal or remote sideWorks by sending TLog recordsConnections are accepted only to the principal databaseNo VNNAutomatic failover with Witness Server

Log Shipping

7

Failover Clustering and Database Mirroring

8

Primary Data Center

Secondary Data Center

SQL Server 2008 R2Failover Cluster

SQL Server 2008 R2Failover Cluster

Asynchronous DatabaseMirroring

Asynchronous Data Movement with Database Mirroring

Database Mirroring and Log Shipping

9

Primary Datacenter

Disaster RecoveryDatacenter2

SQL Server 2008 R2Database Mirroring

SQL Server 2008 R2

Log Shipping

Disaster RecoveryDatacenter1

SQL Server 2008 R2

Log Shipping

Witness

Log Shipping

Synchronous Data Movement with Database Mirroring

Limitations of Current HA/DR Solutions

Solutions are fragmentedDatabase mirroring does not allow multiple secondariesMultiple databases cannot fail over as a groupLog shipping might lose data and does not fail over automaticallyPassive servers are mostly running idleOffloading of reporting and maintenance tasks from the primary server is not easySAN is a single point of failure in failover clustering

10

AlwaysOn Availability Groups

11

AlwaysOn Availability Groups

12

Multiple Secondaries to Improve RedundancyUp to 4Max 2 Sync

AlwaysOn Availability Groups

13

Multiple Secondaries to Improve RedundancyUp to 4Max 2 SyncActive SecondariesOffloading read

workloadsBackups on

Secondary

AlwaysOn Availability Groups

14

Multiple Database Failover

Multiple Secondaries to Improve RedundancyUp to 4Max 2 SyncActive SecondariesOffloading read

workloadsBackups on

Secondary

AlwaysOn Availability Groups

15

Multiple Database Failover

Multiple Secondaries to Improve RedundancyUp to 4Max 2 Sync

Automatic Failover

Flexible Failover Policies for Greater Control over Failover

Active SecondariesOffloading read

workloadsBackups on

Secondary

AlwaysOn Availability Groups

16

Multiple Database Failover

Multiple Secondaries to Improve RedundancyUp to 4Max 2 Sync

Automatic Failover

Flexible Failover Policies for Greater Control over Failover

Active SecondariesOffloading read

workloadsBackups on

Secondary

Virtual Network Name (Listeners)

AlwaysOn Availability Groups

17

Primary Data Center

Reports

A

A

A

A

SecondaryData Center

Replica 1

Replica 3

Replica 2

Replica 4

ReportsBackups

Backups

Multiple Database Failover

Multiple Secondaries to Improve RedundancyUp to 4Max 2 Sync

Automatic Failover

Flexible Failover Policies for Greater Control over Failover

Active SecondariesOffloading read

workloadsBackups on

Secondary

Virtual Network Name (Listeners)

Client Failover using Virtual Name

Availability Group Virtual Name allow applications to failover seamlessly on availability group failover

Application reconnects using a virtual name after a failover to a secondary

18

AGHR

HRDB HRDB

Primary Secondary

HRVNN

-server HRVNN;-catalog HRDB

Application retry during failover

Connect to new primary once failover is completeand the virtual name is online

Primary SecondarySecondary

HRDB

ServerA ServerB ServerC

Readable Secondary

Readable secondary allow offloading read queries to secondaryClose to real-time data, latency of log synchronization impact data freshness Backup ve DBCC CheckDB operations can be done on secondary

19

DB2DB1

SQLservr.exe SQLservr.exe

InstanceA

DB2DB1

Primary Secondary

Database Log Synchronization

InstanceB

Reports

Active Secondary : Read-only RoutingApplicationIntent – A New Connection Property

Used to get access to secondary Applicable when Secondary Replica set with ALLOW_CONNECTIONS =READ_ONLY or YES (ALL)

Connection String

Connect to primary replicaServer=myListener; Database=DB1;

Connect directly to a secondary instanceServer=myListener; Database=DB1; ApplicationIntent = ReadOnly

Read-Only Routing

Connection behavior optimized for automatic routing of read only applications to secondaryYou have to create the routes manually for this to work

20

Active Secondary : Read-only Routing

21

Read-only Routing

Microsoft Confidential22

AGHR

HRDB HRDB

Primary Secondary

HRVNN

-server HRVNN;-catalog HRDB

ServerA ServerB

OLTP

Reports

-server HRVNN;-catalog HRDB; ApplicationIntent = ReadOnly

Read-only Routing

Microsoft Confidential23

AGHR

HRDB HRDB

HRVNN

-server HRVNN;-catalog HRDB

Primary

ServerA ServerB

OLTP

Reports

-server HRVNN;-catalog HRDB; ApplicationIntent = ReadOnly

Secondary

Backup on Secondary ReplicasBackups can be done on any replica of a databaseLog backups done on all replicas form a single log chainBackups on primary replica still worksSupported backup types on secondary:

Full - COPY_ONLY method is only one supported Availability Replica

Transaction LogDifferential - Not Supported

Backup PreferencePrefer SecondarySecondary OnlyPrimaryAny Replica

sys.fn_hadr_backup_is_preferred_replica

24

Availability Group Scenarios

25

Availability Group provides redundancy for databases on both standalone instances and failover cluster instances

Synchronize Asynchronize

A

A

Direct Attached Storage local, regional and geo secondaries

AA

Shared Storage, regional and geo secondaries

A

A

A

Comparison of SQL Server High-Availability and Disaster-Recovery SolutionsTechnology AlwaysOn

Failover Clustering Instances

AlwaysOn Availability Groups

Database Mirroring

Log Shipping

Zero data loss * ** **

Instance Redundancy

Database Redundancy

Auto Failover ** **

Readable Copy *** ****

Multiple Secondaries

*

Microsoft Confidential26

Real-Life Customer Scenario

27

Synchronize Asynchronize

A

A

Primary Data Center

SecondaryData Center

ReportsBackups

Backups

A

FCI

What’s Coming with SQL Server 2014

Increase number of secondaries to 8 (from 4)Increase availability of Readable Secondaries

Use readable secondaries despite network failures (important in geo-distributed environments)

AlwaysOn Availability Groups Add Azure Replica WizardSupport for Windows Server 2012 Cluster Shared Volumes (CSV)Enhanced Diagnostics

28

Thanks!

Questions?Turgay SahtiyanMicrosoft – Senior SQL Server PFE

www.turgaysahtiyan.com

@ @turgaysahtiyan