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.
SQLSaturday Bulgaria : HA & DR with SQL Server AlwaysOn Availability Groups
1. High Availability & Disaster Recovery with
SQL Server AlwaysOn Availability Groups
Turgay Sahtiyan
Microsoft – Senior SQL Server PFE
www.turgaysahtiyan.com
@ @turgaysahtiyan
3. Turgay Sahtiyan
Istanbul, Turkey
Microsoft GBS Team - Senior SQL Server PFE
+12 years IT experience / Last 8 years SQL Server
Key areas : HA&DR Solutions, Performance Tuning, PDW
Community geek
Founder and Former President of SQLPass Turkey Chapter
Former SQL Server MVP
Speaker / Writer / Presenter at Microsoft & SQLSaturdays & Local User
Groups
Social Media
Twitter : @turgaysahtiyan
Blog : www.turgaysahtiyan.com
Linkedin : http://aka.ms/turgaysahtiyan_li
2
4. Agenda
Current HA&DR Solutions
Limitations of Current HA/DR Solutions
SQL Server AlwaysOn Availability Group
Client Failover using Virtual Network Name
Readable Secondary – ReadOnly Routing
Backup on Secondary Replicas
Availability Group Scenarios
Comparison of SQL Server HA&DR Solutions
Demo – AlwaysOn Aavailability Group
Real-Life Customer Scenario
What’s Coming with SQL Server 2014
3
5. SQL Server High Availability
HA&DR solutions before SQL Server 2012 AlwaysOn
Database Mirroring
Failover Cluster Instance
Log Shipping
These features help the customer to reach enough HA&DR
but..
Customers demand more
Better Availability
Higher ROI
Simplicity
4
6. Failover Cluster
Public
SQL Server
Instance
SQL Server
Instance
Shared
Storage
5
Instance level
redundancy
Local or
Remote Site
Presents VNN
Automatic
Failover
Does not
protect
against data
loss
7. Database Mirroring
Witness Server
Mirror Server
Principal Server
Transaction Log Stream
Principal Database
Mirror Database
Client
6
Provide “a” redundant
copy of database
Local or remote side
Works by sending TLog
records
Connections are
accepted only to the
principal database
No VNN
Automatic failover with
Witness Server
9. Failover Clustering and Database Mirroring
Secondary
Data Center
Asynchronous Database
Mirroring
SQL Server 2008 R2
Failover Cluster
Asynchronous Data Movement with Database Mirroring
8
Primary
Data Center
SQL Server 2008 R2
Failover Cluster
10. Database Mirroring and Log Shipping
Log Shipping
Disaster Recovery
Datacenter2
Primary
Datacenter
Log Shipping
Witness
SQL Server 2008 R2
Disaster Recovery
Datacenter1
SQL Server 2008 R2
SQL Server 2008 R2
Database Mirroring
Log Shipping
Synchronous Data Movement with Database Mirroring
9
11. 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
10
12. SQL Server AlwaysOn: Features
AlwaysOn
AlwaysOn
Availability Groups
Failover Cluster Instances
for Database Protection
for Instance Level Protection
• New in SQL Server 2012 with:
• Multiple database failover
• Multiple secondaries
• Active secondaries
• Fast application failover
• Integrated high-availability
management
• Enhanced in SQL Server 2012
with:
• Multi-subnet clustering
• Flexible failover policies
• Improved diagnostics
• Faster failover
• TempDB on local drives
Availability Groups and Failover Cluster Instances rely on Windows Server failover
clustering, which provides a robust and reliable high-availability platform
11
18. AlwaysOn Availability Groups
to Improve
Redundancy
Secondary
Data Center
Replica 4
A
A
Replica 3
A
Backups
Backups
Reports
17
Primary
Data Center
Reports
A
Replica 2
Replica 1
19. 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
ServerA
ServerC
ServerB
HRDB
HRDB
HRDB
AGHR
HRVNN
Primary
Secondary
Primary
Secondary
Application retry during failover
-server HRVNN;-catalog HRDB
18
Connect to new primary once
failover is complete
and the virtual name is online
21. 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 to primary replica
Server=myListener; Database=DB1;
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
20
25. 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
24
26. Availability Group Scenarios
A
A
A
Availability Group provides redundancy
for databases on both standalone
instances and failover cluster instances
A
Direct Attached Storage local, regional and geo secondaries
A
A
A
Synchronize
25
Asynchronize
Shared Storage, regional and geo secondaries
27. Comparison of SQL Server High-Availability
and Disaster-Recovery Solutions
Technology
AlwaysOn
Failover
Clustering
Instances
AlwaysOn
Availability
Groups
Database
Mirroring
Zero data loss
*
**
**
Instance Redundancy
**
**
***
Database
Redundancy
Auto Failover
Readable Copy
Multiple Secondaries
26
*
Microsoft Confidential
Log
Shipping
****
30. 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 Wizard
Support for Windows Server 2012 Cluster Shared Volumes
(CSV)
Enhanced Diagnostics
29
Notes:* Zero data loss is possible with AlwaysOn failover clustering instances only when combined with synchronous SAN replication or synchronous AlwaysOn Availability Groups and /database mirroring.** Zero data loss and automatic failover are possible with synchronous AlwaysOn Availability Groups and database mirroring.*** The mirror database itself is not directly readable, but a static, point-in-time view of it can be read by using a database snapshot.**** The log shipping secondary database can be read when the transaction log backups are restored by using the WITH STANDBY option.
