5. History of AlwaysOn Availability Groups
Background and Predecessor Technologies
6. Comparison of AlwaysOn with other SQL HA
Greatly Improved HA and DR
High Availability and Disaster Potential Potential
Automatic Readable
Recovery Data Loss Recovery
Failover Secondaries
(RPO) Time (RTO)
SQL Server Solution
AlwaysOn Availability Group - synchronous- Zero Seconds Yes 0-2
commit
AlwaysOn Availability Group - asynchronous- Seconds Minutes No 0-4
commit
AlwaysOn Failover Cluster Instance NA Seconds Yes NA
-to-minutes
Database Mirroring - High-safety (sync + witness) Zero Seconds Yes NA
Database Mirroring - High-performance (async) Seconds Minutes No NA
Log Shipping Minutes Minutes No Not during
-to-hours a restore
Backup, Copy, Restore Hours Hours No Not during
-to-days a restore
9. Design Options for SQL 2012
Sample Design
• Two AGs
• Content AG
with four
replicas –
Synch and
Asynch
• Service
App/Farm DBs
on separate
AG, 2 Synch
copies only
• Read-only
farm in remote
office attached
to content DB
copy
• DR farm in
remote DC on
standby to
connect to
content DB
copy
12. AlwaysOn Availability Groups
Prerequisites and Requirements – Windows OS
http://support.microsoft.com/kb/976097
http://support.microsoft.com/kb/2494036
http://support.microsoft.com/kb/2531907
http://support.microsoft.com/kb/2616514
http://support.microsoft.com/kb/2654347
http://support.microsoft.com/kb/980915
http://support.microsoft.com/kb/2578113
http://support.microsoft.com/kb/2582281
14. AlwaysOn Availability Groups
Cluster Witness and Voting Fundamentals
• Automatic failover clustering requires
servers to have the proper number of
votes to ‘turn on’ a database copy.
• There must always be a majority of
votes to enable the node.
• If a majority cannot be reached (for
example, if there are only an even
number of votes) the DBs will remain
offline.
• File Servers can act as File
Share Witness (FSW) servers
(additional votes.)
• This avoids split-brain
scenarios where multiple
copies of a DB are online.
• Very important concept to
understand for AOAG