The AlwaysOn Availability Groups feature is a high-availability and disaster-recovery solution that provides an enterprise-level alternative to database mirroring. Introduced in SQL Server 2012, AlwaysOn Availability Groups maximizes the availability of a set of user databases for an enterprise. In this session we will talk about what’s coming with Always On, and how does it help to improve high availability and disaster recovery solutions.

1. High Availability & Disaster Recovery with
SQL Server 2012 AlwaysOn Availability Group
Turgay Sahtiyan
Microsoft – Senior SQL Server PFE
www.turgaysahtiyan.com
@ @turgaysahtiyan

2. Turgay Sahtiyan
Microsoft – Senior SQL Server Premier Field Engineer
Founder and Former President of SQLPass Turkey Chapter
Former SQL Server MVP
Speaker / Writer / Presenter at SQLSaturdays & Local Events
Social Media
Twitter : @turgaysahtiyan
Blog : www.turgaysahtiyan.com | http://blogs.msdn.com/turgays
Linkedin : http://aka.ms/turgaysahtiyan_li
1

3. SQL Server High Availability
SQL Server High Availability Today
Database Mirroring
Failover Cluster Instance
Log Shipping
Today customers demand more
Better Availability
Higher ROI
Simplicity
2

4. Failover Cluster
3
Public
Shared
Storage
SQL Server
Instance
SQL Server
Instance

5. Database Mirroring
4
Principal Database
Client
Principal Server Mirror Server
Mirror Database
Transaction Log Stream
Witness Server

6. Log Shipping
5

7. Failover Clustering and Database Mirroring
6
Primary
Data Center
Secondary
Data Center
SQL Server 2008 R2
Failover Cluster
SQL Server 2008 R2
Failover Cluster
Asynchronous Database
Mirroring
Asynchronous Data Movement with Database Mirroring

8. Database Mirroring and Log Shipping
7
Primary
Datacenter
Disaster Recovery
Datacenter2
SQL Server 2008 R2
Database Mirroring
SQL Server 2008 R2
Log Shipping
Disaster Recovery
Datacenter1
SQL Server 2008 R2
Log Shipping
Witness
Log Shipping
Synchronous Data Movement with Database Mirroring

9. Limitations of Current HA/DR Solutions
Solutions are fragmented
Database mirroring does not allow multiple secondaries
Multiple databases cannot fail over as a group
Log shipping might lose data and does not fail over
automatically
Passive servers are mostly running idle
Offloading of reporting and maintenance tasks from the
primary server is not easy
SAN is a single point of failure in failover clustering
8

10. SQL Server AlwaysOn: Features
9
Availability Groups and Failover Cluster Instances rely on Windows Server failover
clustering, which provides a robust and reliable high-availability platform
AlwaysOn
Availability Groups
for Database Protection
• New in SQL Server 2012 with:
• Multiple database failover
• Multiple secondaries
• Active secondaries
• Fast application failover
• Integrated high-availability
management
AlwaysOn
Failover Cluster Instances
for Instance Level Protection
• Enhanced in SQL Server 2012
with:
• Multi-subnet clustering
• Flexible failover policies
• Improved diagnostics
• Faster failover
• TempDB on local drives

11. AlwaysOn Availability Groups
10
Primary
Data Center
Reports
A
A
A
A
Secondary
Data Center
Replica 1
Replica 3
Replica 2
Replica 4
Reports
Backups
Backups
Asynchronous Data Movement
Synchronous Data Movement
A
A
Primary Replica
Secondary Replica

12. 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
11
AGHR
HRDB HRDB
Primary Secondary
HRVNN
-server HRVNN;-catalog HRDB
Application retry during failover
Connect to new primary once
failover is complete
and the virtual name is online
Primary SecondarySecondary
HRDB
ServerA ServerB ServerC

13. Readable Secondary
Readable secondary allow offloading read queries to secondary
Close to real-time data, latency of log synchronization impact data
freshness
Backup ve DBCC CheckDB operations can be done on secondary
Auto-create statistics on the secondary replica but persist them in
TempDB
12
DB2DB1
SQLservr.exe SQLservr.exe
InstanceA
DB2DB1
Primary Secondary
Database Log Synchronization
InstanceB
Reports

14. Active Secondary : Read-only Routing
ApplicationIntent – 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 directly to a secondary instance
Server=myListener; Database=DB1; ApplicationIntent = ReadOnly
Read-Only Routing
Connection behavior optimized for automatic routing of read only
applications to secondary
You have to create the routes manually for this to work
13

15. Active Secondary : Read-only Routing
14

16. Backup on Secondary Replicas
Backups can be done on any replica of a database
Log backups done on all replicas form a single log chain
Backups on primary replica still works
Supported backup types on secondary:
Full - COPY_ONLY method is only one supported Availability Replica
Transaction Log
Differential - Not Supported
Backup Preference
Prefer Secondary
Secondary Only
Primary
Any Replica
sys.fn_hadr_backup_is_preferred_replica
15

17. Availability Group Scenarios
16
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
A
A
Shared Storage, regional and geo secondaries
A
A
A

18. Demo
17
Synchronize Asynchronize
A
A
A

19. Real Customer Scenario
18
Synchronize Asynchronize
A
A
Primary
Data Center
Secondary
Data Center
Reports
Backups
Backups
A
FCI

20. Microsoft Confidential19
www.turgaysahtiyan.com
@turgaysahtiyan