This document provides an overview and introduction to SQL Server 2012 high availability and disaster recovery features including log shipping, database mirroring, AlwaysOn availability groups, and SQL Server clustering. It begins with background about the author and an outline of the topics to be covered. The document then goes on to explain each high availability technology individually, providing details on how each works, when they should be used, and the configuration process. Business cases and recommendations for when to use each technology are also provided.
1. SQL Server 2012 High Availability and
Disaster Recovery
Denny Cherry
mrdenny@dcac.co
twitter.com/mrdenny
2. About Me
•
•
•
•
•
•
•
•
Denny Cherry & Associates Consulting
Author or Coauthor of 7 books
8+ SQL Mag articles
Dozens of other articles
Microsoft MVP
Microsoft Certified Master
VMware vExpert
Microsoft Certified Trainer
2
3. I love questions
• Try and keep them on point…
• We can always chat during lunch or after the
session…
• Remember…
– There’s no such thing as a dumb question…
– But don’t take it personally if we all laugh at with
you.
3
4. Today’s Topics
• Database Log Shipping
• Database Mirroring
• AlwaysOn
– Windows and SQL Server Clustering
– Availability Groups
• When should I use each one?
6. What Is Log Shipping?
•
•
•
•
Oldest HA/DR solution available
Backup of logs from one server
Restoring of logs to multiple servers
Allows backup servers to be keep X minutes behind
7. Differences Between Native and Roll
Your Own
Native
• Nice UI for setup
• Easy configuration of
restore delays
• Integrated with SSMS
• Errors can be cryptic
• UI has a couple of bugs
Roll Your Own
• Total control of the process
• Very easy to add or remove
destination servers
• All T-SQL or PoSH Based
9. Rolling Your Own…
• Can be done through all T-SQL or not
• Can use one file, or one file per T-Log backup
• Can be setup to keep one of more targets behind
production
11. Failing Over Log Shipping
•
•
•
•
•
Configure application to use a DNS alias to connect
Fail the database over (methods here vary)
Change DNS to point to the new server
Force DNS replication
Flush DNS cache on all client machines
18. Why do I care about a deprecated
feature?
• Database Mirroring has been deprecated as of SQL
Server 2012
• Feature will be in the product until at least 2016
• Feature will be supported by Microsoft until at least
2026
19. What Does Mirroring Do?
• Keeps a second copy of a database updated
• Runs synchronously or asynchronously
– Synchronous mirroring supported in Standard+
– Asynchronous mirroring supported in Enterprise
21. How does Mirroring Work?
• Feeds a transaction log stream from one machine to
another
• Log is applied and committed as soon as it arrives
22. Database Mirroring Options
Synchronous
• Two or Three Servers
• Supports Automatic Failover
• Standard Edition Feature
• Witness Can Be Express
Asynchronous
• Two Servers
• Enterprise Edition Feature
• Both instances must be EE
30. What Is AlwaysOn?
• Umbrella Term covering multiple features
– SQL Server Clustering
• Local Clustering
• Geographically Dispersed Clusters
– Availability Groups
34. SQL Server Cluster Configuration
• Built on top of Windows Failover Clustering
• Single set of database files
• Multiple instances configured to use these database
files
• Only a Single instance can host the databases at once
39. Instances Redefined
•
•
•
•
Instances are installed on multiple machines
Multiple instances are configured
Each single clustered instance has the same name
Separate clustered instances have different names
40. Instances Redefined
• Each Instance is installed and
managed separately
• Each Instance is installed on
each of the servers of the
cluster (or a subset)
• Each instance requires a
separate network name and
IP address
42. New SQL 2012 Clustering Features
•
•
•
•
Multi-Subnet Failover Support
Network Storage Support
Windows Core Mode Installs
TempDB on local disk
43. Multi-Subnet Failover
• Two different IP Addresses configured for SQL
• Only one comes online at a time using OR statements
within SQL Server
• Uses network subnet configuration to determine IP
to bring online
45. Quorum
• For the cluster to start and stop services, it must
have quorum
• Quorum is the requirement to have a vote, without
being able to have a tie
• Quorum is used to decide which node of the cluster
will host the resource groups
50. Steps to Clustering Windows
• Launch the Clustered Instance wizard
• Select the components to install
• Configure the network name and IP address which
the clustered SQL Server instance will use
• Assign disks to the clustered SQL Instance
• Define the resource group name
51. Multi-Node Installation
• Each instance is installed on each node separately
• Secondary node installations are much simpler
53. Failover Detection
• Cluster Service Logs into SQL Server regularly
• Cluster Service runs a basic query
• Number of failed attempts acceptable can be
configured
• Number of times instance can failover within X
number of minutes can be configured
• Failback is optional (and usually not recommended)
59. Are AG’s Just Mirroring?
• AGs support 4 secondary replicas
– 2 Synchronous
– 4 Asynchronous
•
•
•
•
Transaction Log Stream
Uses encrypted Mirroring endpoint
Secondary Replicas can be read only
Automatic Failover for Synchronous
60. What To Do About Cluster Quorum
Single Site
• Shared Quorum
• Majority Node Set
– Odd number of nodes
Multi Site
• Majority Node Set
– Nodes in DR site disabled
from voting
– Odd Number of nodes in
primary site
61. What To Do About Cluster Quorum
Single Site
• Shared Quorum
• Majority Node Set
– Odd number of nodes
Multi Site
• Majority Node Set
– Nodes in DR site disabled
from voting
– Odd Number of nodes in
primary site
• Asymmetric Disk Only
Quorum
62. FCI + AGs
• Availability Groups can be built on top of FCIs
• Allows for additional redundancy at each site
A
A
A
65. Cross Support With Other Features
•
•
•
•
•
FILESTREAM
FileTable
ColumnStore Indexes
Full Text Indexes
Replication
– Publication
– Subscription
• Contained Databases
• Clustering
• Policy Based
Management
• Maintenance Plans
• Auditing
• User Defined Server
Roles
• Transparent Data
Encryption
• SQL Service Broker
68. Business Case #1
•
•
•
•
•
Single Data Center
No Single Points of Failure
Least Cost
Multiple Redundant Copies
30 minute or less failover time
69. Business Case #2
• All Data is stored on the SAN
• Three Data Centers
– Two Copies of the data in the primary data center
– Two Copies of the data in the secondary data center
– One copy of the data in the tertiary data center
• Short Failover Time
• Automatic Failover To Secondary Data Center
• SAN Replication is available
70. Business Case #3
•
•
•
•
All data is stored on DAS
Six Offices, 50 miles between each
Automatic Failover Between 2 offices
No Single Points of Failure
71. Business Case #4
• All data is stored on the SAN
• 3 Redundant Servers
• Lowest Hardware Costs
72. Business Case #5
• Three Data Centers
– 20 miles between primary and secondary
– 400 miles between primary and 3rd
•
•
•
•
Automatic Failover between primary and secondary
Multiple Servers Per Data Center
All Data on SAN Storage
Lowest Storage Costs