High Availability Solutions in SQL 2012
Download as PPTX, PDF1 like2,091 views
The document summarizes different high availability solutions in SQL Server 2012, including AlwaysOn Failover Cluster Instances, AlwaysOn Availability Groups, and Database Mirroring. It defines key terms like primary/secondary databases and replicas. It also describes the benefits of each solution, such as automatic failover, read-only access on secondaries, and support for different storage options.
High Availability Solutions in SQL 2012
- 1. TECHNET LIVE MEETING High Availability Solutions in SQL Server 2012 Pieter Vanhove
- 2. WHO AM I • Pieter Vanhove • SQL Server Database Consultant at Kohera • MCTS, MCITP Database Administrator 2008 • Love to work with SQL HA/DR solutions • E-mail: pieter.vanhove@kohera.be • Twitter: http://twitter.com/#!/Pieter_Vanhove • Blog: http://blogs.sqlug.be/pieter/ • MEET: http://www.microsoft.com/belux/meet/#Pieter+Vanhove
- 3. AGENDA • What is High Availability • Planned vs. Unplanned downtime • Degraded Availability • Recovery Objectives • Justifying Opportunity Costs • SQL Server AlwaysOn • AlwaysOn Failover Cluster Instance • AlwaysOn Availability Group • Database Mirroring • Log Shipping • Compare the different solutions
- 4. PLANNED VS UNPLANNED DOWNTIME • Planned maintenance. • A time window is preannounced and coordinated for planned maintenance o Software patching o Hardware upgrades o Password updates o Offline re-indexing o Data loading o Rehearsal of disaster recovery procedures • Unplanned outage • System-level, infrastructure, or process failures may occur that are unplanned or uncontrollable • A robust high availability solution o Detects these types of failures o Automatically recovers from the outage o Reestablishes fault tolerance.
- 5. DEGRADED AVAILABILITY • Read-only and deferred operation • Data latency and application responsiveness • Partial, transient, or impending failures
- 6. RECOVERY OBJECTIVES • Recovery Time Objective (RTO) • This is the duration of the outage. The primary goal is to restore full service to the point that new transactions can take place • Recovery Point Objective (RPO) • A measure of acceptable data loss • It is the time gap or latency between the last committed data transaction before the failure and the most recent data recovered after the failure
- 7. JUSTIFYING OPPORTUNITY COSTS • Avoiding downtime • Outage recovery costs are avoided all together if an outage doesn’t occur in the first place • Investments include o The cost of fault-tolerant and redundant hardware or infrastructure o Distributing workloads across isolated points of failure o Planned downtime for preventive maintenance • Automating recovery • If a system failure occurs, you can greatly mitigate the impact of downtime on the customer experience through automatic and transparent recovery • Resource utilization • Secondary or standby infrastructure can sit idle, awaiting an outage • It can be leveraged for read-only workloads • To improve overall system performance by distributing workloads across all available hardware
- 9. WHAT IS FAILOVER CLUSTER INSTANCE Client PCs Public Network San Mirroring Server B (Passive) Server A (Active) Virtual SQL Server Instance Virtual Windows Server Storage Shared Storage Storage
- 10. WHAT IS A FAILOVER Client PCs Public Network Server A Passive Active Virtual SQL Server Instance Server B Passive Switch storage manually DNS change Virtual Windows Server Attach/Detach databases Recreation jobs Shared Storage
- 11. CLUSTER TYPE: ACTIVE/PASSIVE Client PCs Public Network Server A Active Virtual SQL Server Instance Server B Passive Virtual Windows Server Shared Storage
- 12. CLUSTER TYPE ACTIVE/ACTIVE Client PCs Public Network Server A Active Server B Active Virtual Windows Server Shared Storage
- 13. CLUSTER TYPE: ACTIVE/ACTIVE N + 1 Public Network Server A Active Server B Active Server C Passive Shared Storage
- 14. BENEFITS OF FAILOVER CLUSTER INSTANCE • Protection at the instance level through redundancy • Automatic failover in the event of a failure • Support for a broad array of storage solutions • Disaster recovery solution using a multi-subnet FCI • Zero reconfiguration of applications and clients during failovers
- 16. WHAT ARE ALWAYSON AVAILABILITY GROUPS • HA and DR solution that provides an alternative to database mirroring • A container for a discrete set of user databases that fail over together • Multiple possible failover targets • Secondary replicas support read-only access An availability group fails over at the level of an availability replica. Failovers are not caused by database issues
- 17. TERMS AND DEFINITIONS • Primary database • The read-write copy of an availability database • Secondary database • A read-only copy of an availability database • Primary replica • The availability replica that makes the primary databases available for read-write connections • Sends transaction log records for each primary database to every secondary replica • Secondary replica • An availability replica that maintains a secondary copy of each availability database • Serves as a potential failover targets for the availability group • Availability group listener • A server name to which clients can connect in order to access a database in a primary or secondary replica of an AlwaysOn availability group
- 18. SYNCHRONOUS COMMIT MODE 1 Commit 7 Acknowledge 6 Acknowledge Constantly Redoing on Replica 2 Transmit to 2 Write Replica to Local 3 Committed 4 Write to Log in Log Remote Log 5 DB Log Log DB
- 19. ASYNCHRONOUS COMMIT MODE 1 4 Acknowledge Commit 7 Acknowledge Constantly Redoing on Replica 2 Transmit to 2 Write Replica to Local 3 Committed 5 Write to Log in Log Remote Log 6 DB Log Log DB
- 20. FAILOVER TYPES - DBA issues a - Response to a - DBA issues a manual-failover failure forced-failover command command - Primary - Primary Secondary - Primary Secondary Secondary - Synchronous- - Synchronous- commit mode+ - Asynchronous- commit mode failover mode set commit mode to “Automatic” - Replica must be - Replica is not synchronized - Replica must be synchronized synchronized
- 21. READ-ONLY ACCESS ON SECONDARY • You can configure read-only access to the availability replica. • Allows you to offload you read-only workloads from your primary replica • Optimizes resources on your primary replica for your mission critial workloads
- 22. POSSIBLE SETUP
- 23. BENEFITS ALWAYSON AVAILABILITY GROUPS • Supports one primary replica and up to four secondary replicas • Supports Asynchronous-commit mode and Synchronous-commit mode • Read-Only access to the secondary databases • Performing backup operations on secondary databases • Provide fast application failover • Flexible Failover Policy • Automatic page repair • Supports Encryption and Compression • Provides an integrated set of tools
- 24. PREPARATION • Install WSFC on each machine and create a single WSFC cluster • Install SQL Server Instances on each machine • Enable AlwaysOn through SQL Configuration Manager • (CREATE ENDPOINT on each instance)
- 27. TERMS AND DEFINITIONS • Principal Server • Principal server is the server which clients connect to and perform their updates to the database • Mirror Server • Mirror server is performing the same changes on the mirrored database • Witness server • The witness server monitors the status of the principal and mirror servers • The witness does NOT trigger the failover, just helps provide “quorum” • Quorum • In the event of one of the principal becoming unavailable, the mirror can only failover if it can still see the witness, and the witness agrees it cannot see the principal • If the mirror fails, principal can only continue if it still sees the witness
- 28. OPERATING MODES High Availability High Protection High Performance Automatic Detection No Automatic No Automatic Automatic Failover Detection Detection Uses synchronous Manual Failover Manual Failover form of mirroring Uses synchronous form Uses asynchronous Requires Witness of mirroring form of mirroring Principal performance Does not require Does not require is affected by network Witness Witness speed and distance Principal performance Principal performance is affected by network is NOT affected by speed and distance network speed and distance
- 29. SETUP REQUIREMENTS • Both the principal and mirror servers must have SQL 2005 + installed • Both the principal and mirror servers must have space to hold the database • For automatic failover, the witness server also must have SQL Server 2005+ installed • Witness can be any edition, even SQL Server Express • The principal database must use the Full recovery model • The mirror database must be “prepared”
- 30. FAILURE DETECTION • SQL Server • Ping each other once a second • By default if 10 “pings” are missed, then declare a failure • Outside SQL Server • Operating System • Network errors • IO errors • Process errors • Failover speed determined by: • Failure type • REDO queue on the mirror
- 31. BENEFITS DATABASE MIRRORING • Increases availability of a database. • High-safety mode with automatic failover, failover quickly brings the standby copy of the database online (without data loss) • Increases data protection. • Database mirroring provides complete or almost complete redundancy of the data • Mirroring partner running on SQL Server 2008 Enterprise or later versions automatically tries to resolve certain types of errors that prevent reading a data page. Automatic Page Repair • Improves the availability of the production database during upgrades. • To minimize downtime, you can sequentially upgrade the instances of SQL Server • Rolling upgrade
- 32. DATABASE MIRRORING DEPRECATED This feature will be removed in a future version of Microsoft SQL Server. Avoid using this feature in new development work, and plan to modify applications that currently use this feature. Use AlwaysOn Availability Groups instead.
- 33. LOG SHIPPING
- 34. LOG SHIPPING
- 35. TERMS AND DEFINITIONS • Primary database • The database on the primary server that you want to back up to another server. • Secondary database • The warm standby copy of the primary database. o Restoring state o Standby state • Monitor server • When the transaction log on the primary database was last backed up. • When the secondary servers last copied and restored the backup files. • Information about any backup failure alerts.
- 36. TERMS AND DEFINITIONS • Backup job • Performs the backup operation • Logs history to the local server and the monitor server • Deletes old backup files and history information • Copy job • Copies the backup files from the primary server to a configurable destination on the secondary server • Logs history on the secondary server and the monitor server. • Restore job • Restores the copied backup files to the secondary databases. • Logs history on the local server and the monitor server • Deletes old files and old history information. • Alert job • Raises alerts for primary and secondary databases when a backup or restore operation does not complete successfully within a specified threshold.
- 37. LOG SHIPPING CONCEPT Monitor Database Server Log shipping Log shipping Primary Database Secondary Database Server Server Backup Share Restore Job Backup Job
- 38. FAIL OVER TO A LOG SHIPPING SECONDARY 1. Copy any uncopied backup files from the backup share to the copy destination folder of each secondary server. 2. Apply any unapplied transaction log backups in sequence to each secondary database. 3. If the primary database is accessible, back up the active transaction log and apply the log backup to the secondary databases. 4. After the secondary servers are synchronized, you can fail over to whichever one you prefer by recovering its secondary database and redirecting clients to that server instance. Recovering puts the database into a consistent state and brings it online.
- 40. COMPARING FAILOVER Failover Availability Database Log Shipping clustering Groups Mirroring • SQL Server • Database • Database • Database Instance Group • Manual or • Manual • Automated • Manual or automated • Based on • Within automated • Few seconds configuration minutes • Few seconds to minutes • Forced • No to minutes • Application application application • No redirection redirection redirection Application required (can required required redirection be required automated)
- 41. COMPARING SECONDARY SERVER Failover Availability Database Log Shipping clustering Groups Mirroring • Instance • Database • Database • Database • Multiple nodes • Up to 4 • Principal and • Multiple • Server in same Secondary Mirror secondary LAN Replica’s • Span across nodes • Hot standby • Span across WAN • Span across server WAN • Hot standby WAN • Available for • Hot standby • Not available • Warm standby use • Available for for use • Available for • Shared storage use • Storage need use • Status check • Storage need not be shared • Storage need using not be shared • No status check not be shared Heartbeat • Status check unless using • No status WFC witness checking
- 42. COMPARING Failover Availability Database Log Shipping clustering Groups Mirroring • All instance • Configured • Configured • Configured databases are database is database is database logs shared mirrored or mirrored are applied • Loss limited to readable • Loss limited to • Loss limited to last hardened • Loss limited to last mirrored last applied record last mirrored transaction transaction • No data copy transaction • Synchronous log backup across • Synchronous or • Transaction network or Asynchronous log Asynchronous mirroring Backup, Copy commit mode and Restore
- 43. COMPARING Failover Availability Database Log Shipping clustering Groups Mirroring • Network • Network • Network • Network connectivity latency to latency to latency to needs to meet I/U/D meet I/U/D meet RTO meet SLA’s SLA’s • Transaction heartbeat • Data is • Data is Log file requirements transferred transferred records • Data is not over network over network transferred transferred over network over network
- 44. WRAP UP • What is High Availability • Planned vs. Unplanned downtime • Degraded Availability • Recovery Objectives • Justifying Opportunity Costs • SQL Server AlwaysOn • AlwaysOn Failover Cluster Instance • AlwaysOn Availability Group • Database Mirroring • Log Shipping • Compare the different solutions
- 45. RESOURCES • AlwaysOn Team Blog • http://blogs.msdn.com/b/sqlalwayson/ • SQL Server 2012 Whitepapers • http://msdn.microsoft.com/en-us/library/hh403491 • MSDN – SQL Server High Availability Solutions • http://msdn.microsoft.com/en- us/library/ms190202.aspx#RecommendedSolutions
- 46. © 2011 Microsoft Corporation. All rights reserved. Microsoft, Windows, Windows Vista and other product names are or may be registered trademarks and/or trademarks in the U.S. and/or other countries. The information herein is for informational purposes only and represents the current view of Microsoft Corporation as of the date of this presentation. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information provided after the date of this presentation. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION.