Assaf Fraenkel Principal Consultant Microsoft Consulting Services High Availability with SQL 2005 זמינות יתרה והמשך פעילות עסקית

Download Assaf Fraenkel Principal Consultant Microsoft Consulting Services High Availability with SQL 2005 זמינות יתרה והמשך פעילות עסקית

Post on 22-Dec-2015

215 views

Category:

Documents

1 download

Embed Size (px)

TRANSCRIPT

<ul><li> Slide 1 </li> <li> Assaf Fraenkel Principal Consultant Microsoft Consulting Services High Availability with SQL 2005 </li> <li> Slide 2 </li> <li> Availability Stack Majority of downtime is ascribed to operators Application Software can have dramatic impact on fault tolerance System Software can help at all levels Hardware is very reliable at this point Hardware SystemSoftware ApplicationSoftware Operators </li> <li> Slide 3 </li> <li> Barriers To Availability SS 2005 gives you greatly improved tools to overcome these barriers Database Server Failure or Disaster User or Application Error Data Access Concurrency Limitations Database Maintenance and Operations Upgrades Only some are addressable by DBMS technology Be sure to consider people, planning, and procedures </li> <li> Slide 4 </li> <li> Availability Solutions How Do You Compare the Alternatives (1/2) Time to Fail Over Automatic or Manual Detection Automatic or Manual Failover Number of Failures it can survive Data Currency / Loss </li> <li> Slide 5 </li> <li> Availability Solutions How Do You Compare the Alternatives (2/2) Granularity of Data: Instance, Database, Table, Row Cost of redundant system(s), additional hardware, additional management Complexity Data Consistency Transparency to clients </li> <li> Slide 6 </li> <li> Availability Technologies in SQL Server 2005 </li> <li> Slide 7 </li> <li> Basic: No failover and a potential data loss Backup / restore Detach / copy / attach Better: Manual failover - potential data loss Peer-to-Peer Replication Log Shipping Database Mirroring - high performance mode Best: Automatic failover - zero data loss Database Mirroring - high availability mode Failover Clustering </li> <li> Slide 8 </li> <li> Backup / Restore Detach / Copy / Attach Cold Standby Solutions Backup / Restore and Detach / Copy / Attach </li> <li> Slide 9 </li> <li> Both Provide Manual detection and failover Potential for some work loss Whole-database scope Standard servers Limited reporting on standby Duplicate copy of database Client must know where to re-connect Slowest failover Most downtime Cold Standby Solutions Backup / Restore and Detach / Copy / Attach </li> <li> Slide 10 </li> <li> Backup / Restore Whats New in SQL Server 2005 Fine-Grained Online Repair Online Restore Database remains online; Only data being restored is offline Piecemeal Restore Online restore of filegroups by priority Page-level Restore Can restore individual pages to repair errors found by page checksum or torn pages Instant File Initialization Skips file zeroing, fast DB create / restore Data backups do not block log backups Restore read-only filegroups without applying logs Backup / Restore includes FullText data </li> <li> Slide 11 </li> <li> Warm Standby Solutions Replication and Log Shipping Replication Log Shipping </li> <li> Slide 12 </li> <li> Warm Standby Solutions Replication Multiple copies and Manual failover Primarily used where availability is required in conjunction with scale out of read activity Failover possible; a custom solution Not limited to entire database; Can define subset of source database or tables Copy of database is continuously accessible for read activity Latency between source and copy can be as low as seconds Replication </li> <li> Slide 13 </li> <li> Peer-to-Peer Transactional Replication All participants are peers Schema is identical on all sites Publish the updates made on their data Subscribe to others to pick up their changes No hierarchy as in normal transactional replication A given set of data can be updated at only one site at a time Data ownership is purely logical; doesnt prevent conflicts SQL Server prevents a change from round-tripping Enables load-balancing and high availability Warm/hot standby - Small possibility of data loss Peer-to-Peer Transactional Replication </li> <li> Slide 14 </li> <li> Warm Standby Solutions Log Shipping Multiple copies and Manual failover Basic idea: Backup, Copy &amp; Restore Log will always be supported But no more investment in the scripts Database scope Database accessible but read-only Users must exit for next log to be applied Data backups no longer block log backups Log Shipping </li> <li> Slide 15 </li> <li> Hot Standby Failover Solutions Failover Clustering and Database Mirroring Both Provide Automatic detection Automatic, fast failover Manual failover Transparent client redirect Zero work loss Database Mirroring Failover Cluster </li> <li> Slide 16 </li> <li> Zero work loss, zero impact on throughput Instance Failover instance fails as a unit Single copy of instance databases Standby is not available for reporting, queries, etc. May support other instances Failover Clustering Microsoft Server Cluster Failover Cluster * Inst1 </li> <li> Slide 17 </li> <li> Failover Clustering SQL Server 2005 More nodes Match operating system limits Supported scenarios: Multiple Active Instances, N+1, N+I Two-node Failover Clustering is available in SQL Server 2005 Standard Edition Unattended setup Support for mounted volumes (Mount Points) All SQL Server data services participate Database Engine, SQL Server Agent, Full-Text Search Analysis Services supports multiple instances N+1: N Active, 1 Inactive Instances * Inst1 Inst2 * Multiple Active Instances N+I: N Active, I Inactive Instances </li> <li> Slide 18 </li> <li> Database Mirroring New for SQL Server 2005 Hot Standby Database Failover Very fast failover Less than five seconds in most cases Zero data loss Automatic or manual failover Automatic re-sync after failover Automatic, transparent client redirect Database Mirroring </li> <li> Slide 19 </li> <li> Fault Tolerant Virtual Database Principal Clients Witness Mirror </li> <li> Slide 20 </li> <li> Witness and Quorum Sole purpose of the Witness is to provide automatic failover To survive the loss of one server you must have at least three Witness is an instance of SQL Server 2005 Perhaps even SQL Server Express on WinXP Consumes very little resources Can be witness for multiple sessions Witness </li> <li> Slide 21 </li> <li> Database Mirroring How it works Mirror Principal Witness Log ApplicationSQL Server 2 2 4 5 1 Data Log 3&gt;2&gt;3 Mirror is always redoing it remains current Commit </li> <li> Slide 22 </li> <li> Safety / Performance There is a trade-off between performance and safety Database Mirroring has two safety levels FULL commit when logged on Mirror Allows automatic failover No data loss OFF commit when logged on Principal System does its best to keep up Prevents failover; to make mirror available Must force service Or terminate Database Mirroring session </li> <li> Slide 23 </li> <li> Database Mirroring Modes High-Availability Mode Safety Full; Synchronous operation Database is available whenever a quorum exists Automatic failover High-Protection Mode Safety Full; Synchronous operation No witness quorum provided by partners If Principal loses quorum, it stops servicing the database Ensures high protection; database is never in exposed state Manual failover only; no automatic failover A transition mode; should not be in this mode for long High-Performance Mode Safety Off; Asynchronous operation Manual failover only Supports only one form of role switching: forced service (with possible data loss) </li> <li> Slide 24 </li> <li> Database Mirroring High Availability Mode Principal Clients Witness Mirror X High Protection Mode High Performance Mode </li> <li> Slide 25 </li> <li> Transparent Client Redirect No changes to application code Client automatically redirected if session is dropped Client library is aware of Principal and Mirror servers Upon initial connect to Principal, library caches Mirror name When client attempts to reconnect If Principal is available, connects If not, client library automatically redirects connection to Mirror </li> <li> Slide 26 </li> <li> Database Mirroring Impact to transaction throughput Depending on environment Depending on workload Zero to minimal Hardware Works with standard computers, storage, and networks No shared storage components, virtually no distance limitations My Tips: 1GB Network, Disk for the Log Database Mirroring </li> <li> Slide 27 </li> <li> Initiating a Database Mirroring Session Create endpoints for communication CREATE ENDPOINT CREATE ENDPOINT On the principal server, back up the database BACKUP DATABASE AdventureWorks TO DISK = 'c:\AdventureWorks.bak' On the future mirror server, restore the database RESTORE DATABASE AdventureWorks FROM DISK = 'z:\AdventureWorks.bak' WITH NORECOVERY On the mirror, set the principal server as a failover partner ALTER DATABASE AdventureWorks SET PARTNER = 'sqlDbEngine05\MSSQLSERVER' On the principal server set the mirror server as the second failover partner ALTER DATABASE AdventureWorks SET PARTNER = 'sqlDbEngine06\MSSQLSERVER' To fail over: On the principal ALTER DATABASE db SET PARTNER FAILOVER To view metadata SELECT * FROM SYS.DATABASE_MIRRORING SELECT * FROM SYS.DATABASE_MIRRORING_ENDPOINTS SELECT * FROM SYS.DATABASE_MIRRORING_WITNESSES </li> <li> Slide 28 </li> <li> 3 rd Party Business Continuance Solutions Many solutions by many companies with many different names Most replicate data and log changes by one of these methods Looking into SQL Servers log files and translating log records into logical operations Intercepting IOs and duplicating them, either to another disk set or simply recording them Replicating the writes at the storage level Local copies / mirrors for snapshot backups, etc. Remote copies / mirrors for disaster recovery and Geographically-Dispersed Clusters </li> <li> Slide 29 </li> <li> Microsoft SQL Server Core I/O Requirements I/O- and Storage-Level Replication See whitepaper SQL Server 2000 I/O Basics on TechNet http://www.microsoft.com/technet/prodtechnol/sql/2000/maintain/sqlIObas ics.mspx http://www.microsoft.com/technet/prodtechnol/sql/2000/maintain/sqlIObas ics.mspx To ensure correct operation the underlying I/O and storage system must meet the Core I/O Requirements Stable Media once write is acknowledged, must be guaranteed Write Ordering writes must preserve ordering across devices Torn I/O Prevention writes must be done as a unit; not split Applies to both local storage and any I/O-level or storage-level replication scheme, synchronous or asynchronous Guarantees that what appears at secondary site is an image that actually appeared at some point in time at the primary Asynchronous replication allows potential loss of committed transactions </li> <li> Slide 30 </li> <li> Geographically-Dispersed Clusters and Storage-level Replication Solutions from many Microsoft partners replicate the local I/Os on a remote system Hardware and software methods Synchronous and asynchronous solutions Solutions must meet Core I/O Requirements Many solutions use MSCS to provide automatic failover Other solutions are primarily to duplicate the data at a remote site, often with an independent SQL Server Similar to Log Shipping or Detach / Attach Geographical Failover Cluster </li> <li> Slide 31 </li> <li> Complementary Technologies Technologies can be Combined Maximize availability for Scale out Offload primary data platform Heavy reporting Mobile/disconnected users Autonomous business units that share data Maximize availability of critical systems Designed for failover Fast, automatic Zero data loss Transactionally current Masks planned and unplanned downtime Replication Failover Solutions </li> <li> Slide 32 </li> <li> Example Fault-Tolerant Publisher and Distributor Subscribers Complementary Technologies Failover Solution + Replication Distributor Publisher </li> <li> Slide 33 </li> <li> Combining HA Technologies Principal Server can be a Failover Cluster Failover to mirror will occur before failover within the cluster So Principal will come back up as the Mirror Mirror can be a Failover Cluster as well PrincipalMirror Failover Cluster </li> <li> Slide 34 </li> <li> Barriers To Availability As addressed in SQL Server 2005 Database Server Failure or Disaster ------------------------------------------------------------ Application or User Error Database Snapshots Data Access Concurrency Limitations Database Maintenance and Operations Upgrades </li> <li> Slide 35 </li> <li> Barriers to Availability This job would be great if it werent for the users the staff us People Im going to modify this dataright here ! </li> <li> Slide 36 </li> <li> Database Snapshot New in SQL Server 2005 Database Snapshots allow recovery from user errors by allowing the database to go back in time Works with Single server Database Mirroring Failover Cluster Does not work with Log Shipping secondary </li> <li> Slide 37 </li> <li> Database Snapshot How it really works mydbSnap Read-Only Database Snapshot USE mydbSnap SELECT (pages 4, 6, 9, 10, 14) 1 Page 2345678910111213141516 CREATE DATABASE mydbSnap AS SNAPSHOT OF mydb mydb Database USE mydb UPDATE (pages 4, 9, 10) 4 910 12345678910111213141516 </li> <li> Slide 38 </li> <li> Database Snapshot Snapshot of an entire database at a point in time Created instantly Read only Snapshot must be created before the error Base database continues to change Database Snapshot does not restrict the base database Multiple Snapshots are allowed Database Snapshots can exist forever Constrained by resources </li> <li> Slide 39 </li> <li> Database Snapshot Uses Static, time-consistent copy for reports With Database Mirroring enables reporting on the standby No increase in failover time Recover from User, Application, or DBA error Revert database to previously created Database Snapshot Takes the database back in time Very fast, no restoring of backups required </li> <li> Slide 40 </li> <li> Database Snapshot Technology Extremely space efficient Does not require a complete copy of the data Shares unchanged pages of the database Requires extra storage only for changed pages Uses a copy-on-write mechanism Database Snapshot may affect performance on the base database </li> <li> Slide 41 </li> <li> Database Snapshot Syntax Examples To create a database snapshot CREATE DATABASE mydbSnap0600 ON ( ) AS SNAPSHOT OF mydb To drop a database snapshot DROP DATABASE mydbSnap0600 To revert a database to a snapshot RESTORE DATABASE mydb FROM DATABASE_SNAPSHOT = 'mydbsnap0600' </li> <li> Slide 42 </li> <li> Reporting on a Mirror Use Database Snapshots on Mirror Mirror Principal Reporting Clients Database Mirroring OLTP Clients Snapshot1 at 1PM Witness Snapshot2 at 2PM </li> <li> Slide 43 </li> <li> Barriers To Availability As addressed in SQL Server 2005 Database Server Failure or Disaster Application or User Error Data Access Concurrency Limitations Snapshot Isolation Online Index Operations Database Maintenance and Operations Upgrades </li> <li> Slide 44 </li> <li> Snapshot Isolation New in SQL Server 2005 Two new snapshot isolation levels Increased data availability for read applications Allows non-blocking consistent reads in an online transaction processing (OLTP) environment Writers do not block readers; readers do not block...</li></ul>