Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                
SlideShare a Scribd company logo

SQLSaturday Bulgaria : HA & DR with SQL Server AlwaysOn Availability Groups

•Download as PPTX, PDF•
•

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 of 31
High Availability & Disaster Recovery with SQL Server AlwaysOn Availability Groups Turgay Sahtiyan Microsoft – Senior SQL Server PFE www.turgaysahtiyan.com @ @turgaysahtiyan
Sponsors
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
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
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
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
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
Log Shipping 7
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
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
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
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
AlwaysOn Availability Groups to Improve Redundancy 12
AlwaysOn Availability Groups to Improve Redundancy 13
AlwaysOn Availability Groups to Improve Redundancy 14
AlwaysOn Availability Groups to Improve Redundancy 15
AlwaysOn Availability Groups to Improve Redundancy 16
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
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
Readable Secondary SQLservr.exe Primary Secondary SQLservr.exe InstanceA InstanceB Database Log Synchronization DB1 DB2 DB1 DB2 Reports 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 19
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
Active Secondary : Read-only Routing 21
Read-only Routing ServerB ServerA AGHR HRDB HRDB Primary Secondary HRVNN Reports OLTP -server HRVNN;-catalog HRDB 22 -server HRVNN;-catalog HRDB; ApplicationIntent = ReadOnly Microsoft Confidential
Read-only Routing ServerB ServerA AGHR HRDB HRDB Secondary Primary HRVNN Reports OLTP -server HRVNN;-catalog HRDB 23 -server HRVNN;-catalog HRDB; ApplicationIntent = ReadOnly Microsoft Confidential
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
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
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   **** 
Demo Synchronize Secondary Data Center Asynchronize Primary Data Center A A A Replica 3 Reports myListener 27 Replica 2 Replica 1
Real-Life Customer Scenario Primary Data Center A FCI A Secondary Data Center A Backups Reports Backups Synchronize 28 Asynchronize
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
Sponsors

More Related Content

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
  • 13. AlwaysOn Availability Groups to Improve Redundancy 12
  • 14. AlwaysOn Availability Groups to Improve Redundancy 13
  • 15. AlwaysOn Availability Groups to Improve Redundancy 14
  • 16. AlwaysOn Availability Groups to Improve Redundancy 15
  • 17. AlwaysOn Availability Groups to Improve Redundancy 16
  • 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
  • 20. Readable Secondary SQLservr.exe Primary Secondary SQLservr.exe InstanceA InstanceB Database Log Synchronization DB1 DB2 DB1 DB2 Reports 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 19
  • 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
  • 22. Active Secondary : Read-only Routing 21
  • 23. Read-only Routing ServerB ServerA AGHR HRDB HRDB Primary Secondary HRVNN Reports OLTP -server HRVNN;-catalog HRDB 22 -server HRVNN;-catalog HRDB; ApplicationIntent = ReadOnly Microsoft Confidential
  • 24. Read-only Routing ServerB ServerA AGHR HRDB HRDB Secondary Primary HRVNN Reports OLTP -server HRVNN;-catalog HRDB 23 -server HRVNN;-catalog HRDB; ApplicationIntent = ReadOnly Microsoft Confidential
  • 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   **** 
  • 29. Real-Life Customer Scenario Primary Data Center A FCI A Secondary Data Center A Backups Reports Backups Synchronize 28 Asynchronize
  • 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

Editor's Notes

  1. 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.