AlwaysOn: Availability Groups
description
Transcript of AlwaysOn: Availability Groups
AlwaysOn: Availability Groups
[email protected] ILIKESQL.COM
@ilikesqlDandy Weyn
MODIFY THIS SLIDE FOR ACTUAL PRESENTER, DELETE THIS BAR AFTER MODIFICATION
SQL SERVER DELIVERS REQUIRED 9SMaximize uptime for mission critical applications
GREATER HARDWARE UTILIZATION
AlwaysOn High AvailabilityWindows Server Core Support Online Operations Enhancements
Active SecondariesScale Read-Only Applications Offload BackupsFast Application Failover
Integrated Configuration WizardWindows PowerShell Support AlwaysOn DashboardMicrosoft System Center Monitoring
IMPROVED PRODUCTIVITY
GREATER UPTIME
GREATER UPTIME WITH HIGH AVAILABILITYKey technologies to deliver required 9s
Availability Groups provide database level
protection
Multiple Secondaries
Failover Cluster Instances provide
instance level protection
Reduce OS patching by as much as 50-
60% with new support for Windows Server
Core1
Reduce planned downtime by
reducing OS patching
Maintain uptime during
maintenance operations using enhanced online
operations
Reindexing of large object data types
Adding non-null columns
1The percentage reduction in patching varies & can be less based on the server roles that are enabled & the type of patches that are applied.
SQL SERVER 2012 HA & DR SOLUTIONS
1Multi-site Failover Cluster Instance (FCI) for HA & DR
• Shared Storage solution• Instance Level HA • Instance Level DR• Doesn’t require database to be in FULL
recovery model
2 Availability Group for HA & DR
• Non-Shared Storage solution• (Group of) Database Level HA• (Group of) Database Level DR• DR replica can be Active Secondary• Requires database to be in FULL recovery
model
3Failover Cluster Instance for local HA & Availability Group for DR
• Combined Shared Storage and Non-Shared Storage
• Instance Level HA • (Group of) Database Level DR• DR replica can be Active Secondary• Requires database to be in FULL recovery
model
• Active Secondary––
–
• Monitoring and Troubleshooting enhanced
• Automation using PowerShell
ALWAYSON AVAILABILITY GROUPSAlwaysOn Availability Groups is a new feature that enhances
and combines database mirroring and log shipping capabilities
• Multi-database failover• Multiple secondaries
––
–
• Synchronous and asynchronous data movement
• Built in compression and encryption
• Auto-page repair• Automatic and manual
failover (new design)• Flexible failover policy
• Application failover using virtual name
• Configuration Wizard• Dashboard• System Center
Integration• Rich diagnostic
infrastructure• File-stream replication• Replication publisher
failover
Flexible Integrated Efficient
ALWAYSON AVAILABILITY GROUP LISTENER
TechAG1
2 DB
2 DB
Primary SecondaryTechListener
1
Parameter Sample: -server TechListener1;-catalog HRDB
Application retry during failover
Primary SecondarySecondary
2 DB
ServerA ServerB ServerC
Availability Groups Listener allow applications to failover seamlessly to any secondary; reconnecting through Virtual Network Name
Connect to new primary once failover is completeand the listener is online
ALWAYSON AVAILABILITY GROUP ARCHITECTURE
Inter-node health detection Failover coordination Primary health detectionDistributed data store for settings and stateDistributed change notifications
SQL Server AlwaysOn Failover Cluster InstancesSQL Server AlwaysOn Availability GroupMicrosoft Hyper-VMicrosoft ExchangeBuilt-in WSFC workloads (e.g. file share, NLB, etc.) and third party workloads
Availability Group uses WSFC for
DatabaseActive Log Synchronization
DatabaseActive Log Synchronization
Windows Server Failover Clustering(WSFC)
WSFC is a Common Microsoft Availability Platform
NEW TOPOLOGY BENEFITSBetter SLAs Easier Deployment &
ManagementMultiple no data loss secondaries
Better data loss protection for DR secondaries through continuous
replicationFaster failover to DR secondaries
through virtual name failover
Unified solutionSimple deploymentUnified dashboardRich diagnostics
Centralized management of client connection topologyMulti-DB failover
New Management Dashboard
ALWAYSON ACTIVE SECONDARIES
IT EFFICIENCY AND COST-EFFECTIVENESS ARE CRITICAL FOR BUSINESSESIdle hardware is no longer an option.
ACTIVE SECONDARY USESRead-only workloadsOffloading Backups
AlwaysOn Active Secondary enables efficient utilization of high availability hardware resources to improve overall IT efficiency
SQLservr.exe SQLservr.exe
ACTIVE SECONDARY – READABLE SECONDARY
Readable secondary allow offloading read queries to secondaryLow data latency
After failover, the read applications can be automatically redirected to the new Secondary (require explicit connection request)Not a replacement for replication scenarios
Primary SecondaryPrimarySecondary
Database Log Synchronization
DB2DB1
InstanceB
Reports
DB2DB1
InstanceA
Reports
CRASH
SecondaryPrimary
Log Cache
Log Cache
READABLE SECONDARY – DATA LATENCY
Secondary read is always behind primary during transaction activity
DB1
DB1 Log
DB1Log
Capture Log Receive
DB1 Data
Network
Redo Thread
Redo Pages
DB1 Log DB1 Data
Log HardenedLog Flush
Commit
Acknowledge Commit
Log Pool
Log Capture
READ WORKLOAD IMPACTCONCURRENCY AND BLOCKINGREDO can get blocked by reporting workloadREDO thread and read workload can deadlockSOLUTIONInternally map read workload to non blocking isolation levels (no application changes required)• Read Uncommitted Snapshot Isolation• Read Committed Snapshot Isolation• Repeatable Read Snapshot Isolation• Serializable Snapshot Isolation• Ignore all locking hints
Never choose REDO as deadlock victim
PRIMARY SECONDARIES
ReadRead/Write
RESULTBlocking and deadlock between Reporting workload (i.e. Query) and REDO thread is eliminatedNo issues with DML (INSERT/DELETE/UPDATE) as it is not allowedWill incur additional cost of row versioning.
CLIENT CONNECTIVITYREAD / WRITE WORKLOAD• Connecting using AG Listener• Connection using FAILOVER_PARTNER (if
connection string of existing applications can’t be changed)
READ ONLY WORKLOAD• Connection using VNN and
ApplicationIntent=ReadOnly• Connection to the secondary instance
directly• ReadOnly Routing
MULTI SUBNET FAILOVER SCENARIO:• New client libraries =>
MultiSubnetFailover=True• Old client libraries configure appropriate
client connection timeout
CLIENT
AG Listener
PRIMARY SECONDARIES
BACKUP CAPABILITIES
Backups from any replica
Synchronous or asynchronous secondaries
Primary backups still work
Adds capacity to primary server by off-loading backups to a
replica
Log backups done on all replicas
form a single log chain
Recovery Advisor makes restores simple
RECOVERY ADVISOR
CONSIDERATIONS FOR AVAILABILITY GROUPS
All SQL servers (including the secondary in the DR site) in the same Windows domain• One Windows Server Failover Cluster spreads
over the primary and DR sitesAll the databases must be in FULL recovery modelThe unit of failover (for local HA, as well as DR) is at the AG level, i.e., group of databases – not the instance• Consider using Contained Database for
containing logins for failover• For jobs and other objects outside the
database, simple customization neededNo delayed apply on the secondary like log shippingRemoving log shipping means the regular log backup job is removed• Need to re-establish periodic log backup
(essential for truncating the log)
New Tools for Monitoring &
AlertingAlwaysOn Dashboard
System Center Operations Manager
Failover Clustering Improvements
DEMO
ALWAYSON MULTI-SITE FAILOVER CLUSTER INSTANCEProvide High Availability at the Instance Level• Unit of failover = SQL server instance• Maintain same virtual network name after failover. Clients re-connect to same
name• Instance restart requires database to go through recovery
Provide Disaster Recovery at the Instance Level• Provide Disaster Recovery protection from site failure: be it network, power,
infrastructure or other site disasters.• Require storage based replication technology and networking considerations• Multi-subnet support:
HA & DR Solution
Version Native Support Implementation
SQL Server 2008 R2 NO • Create stretch Virtual-LAN (VLAN) to act as a
single subnet
SQL Server 2012 YES• IP address OR dependency support within
SQL Server setup• SQL Engine skips binding to IP’s not online on
start-up
MULTI-SUBNET CLUSTERINGCorpnet
Network Name: SqlClust
subnet 1 subnet 2
IP1: 10.168.0.10 IP2: 192.168.0.10
SAN ReplicationLocal Site Remote Site
ORNode1Node2
Node3Node4
TEMPDB ON LOCAL DISKWHY WE ENABLE THIS?• tempdb access occupies large %
of SAN I/O• Fast local HDD/SSD becomes
standard Server configuration
BENEFITS• Better overall performance• Cost saving
IMPORTANT NOTE! • Ensure that tempdb local paths
are available to SQL Service on all the nodes
LOCAL TEMP DB
(Fast disk, SSD)
Shared Disk (SAN)
LOCAL TEMP DB
(Fast disk, SSD)
SECONDARIESPRIMARY
ALWAYSON FAILOVER CLUSTER INSTANCEFailover Condition PolicyFlexible Failover Policy provides administrators control over the conditions when an automatic failover should be initiated.
Resource DLL
SQL Server
Select @@servername
SQL Server 2008 R2 SQL Server 2012
Resource DLL
SQL Server
sp_server_diagnostics
Diagnostics
Configurable options eliminate false failoverImproved logging for better diagnostics
SQL Server Hands-on-Labs
SQLSERVERLAUNCH.COM