National Manager Database Services SQL Server High Availability Craig Ryan National Manager Database Services

Agenda How much Availability do you need? SQL 2000 High Availability Options Log Shipping, Replication, Clustering Demo – SQL 2000 H.A Options New HA options in SQL 2005 Database Mirroring Demo – SQL 2005 Database Mirroring

How Much Availability do you need? Need to ask yourself: How long can we afford to be down? How much data can we afford to lose? Availability = up/(up+down) Once you have the answers to these questions you can match the HA options to the business requirements. the IT department generally cannot answer these questions. When planning an HA strategy you need to look at what is already available. i.e is there a DR plan, maybe DR hardware or a DR site. If your current H/W is struggling this can be a problem as some HA options require additional resources. The degree to which an application or service is available when, and with the functionality, users expect

Barriers To Availability Many barriers Only some are addressable by DBMS technology Be sure to consider people, planning, and procedures Database Server Failure or Disaster User or Application Error Data Access Concurrency Limitations Database Maintenance and Operations Upgrades Availability at Scale

Warm Standby Solutions Replication and Log Shipping Database Object Level SQL Server Replication Database Level Log Shipping Both provide multiple copies and a MANUAL fail over

Log Shipping Minimal impact on the production server No changes to the database are required Transactional consistency Supports delayed load of transaction logs Not all SQL Server objects are automatically copied Users must exit for next log to be applied Failback can be time consuming

Demo SQL 2000 Log Shipping

Replication 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 Significantly increases the on-going Database management Database schema may need to be changed Merge Repl – instant failback

SQL 2000 Transactional Replication Demo SQL 2000 Transactional Replication

Failover Clustering Microsoft Cluster Services Hot Standby – Automatic failover Built on Microsoft Cluster Services (MSCS) Multiple nodes provide availability, transparent to client Automatic detection and failover Requires certified hardware Supports many scenarios: Active/Active, N+1, N+I Instance Failover – entire instance works as a unit Single copy of instance databases Available since SQL Server 7.0 Standby is not available for reporting, queries, etc. May support other instances Needs SQL 2000 Enterprise Edition Needs Windows 2000 Enterprise Edition Shared Nothing Arch

Active/Passive SQL Server Cluster Client PCs SQL Server Virtual Server Server A Server B Heartbeat Cluster management Hub Shared Disk Array Hub E F G C,D C,D SQL Server

Active/Passive SQL Server Cluster Client PCs SQL Server Virtual Server Server A Server B Heartbeat Cluster management Hub Shared Disk Array Hub SQL is shutdown and restarted on Server B. Therefore clients will be disconnected and have to reconnect. E F G C,D C,D SQL Server

What Clustering doesn’t do: Clustering is not a mechanism to scale Doesn’t protect your server against site outage Doesn’t protect your disk subsystem Doesn’t protect against database corruption Doesn’t protect against logical corruption Doesn’t protect against user error Doesn’t protect application crash Clustering is not a method to load-balance Still a single point of failure – The Database!

SQL 2000 Failover Clustering Demo SQL 2000 Failover Clustering

Log Shipping vs Clustering vs SQL Replication So what’s the best solution…. … it depends … On your business requirements You can combine the SQL H.A options. E.g. A/P Cluster with Log shipping

SQL Server 2005 High Availability

Barriers To Availability As addressed in SQL Server 2005 Database Server Failure or Disaster Failover Clustering Database Mirroring Transparent Client Redirect User or Application Error Data Access Concurrency Limitations Database Maintenance and Operations Availability at Scale User: Good management tools, automation, and defined procedures help prevent many potential mistakes Database Snapshot Data Access Concurrency Limitations Snapshot Isolation Database Maintenance Online Index operations Fast Recovery Online restore, restore a database while it remains online Data backups don’t block log backups Full Text catalogs backed up & restored as part of the database

Failover Clustering SQL Server 2005 Further refined in SQL Server 2005 More nodes Match operating system limits Unattended setup Support for mounted volumes (Mount Points) All SQL Server services participate Database Engine, SQL Server Agent, Analysis Services, Full-Text Search, etc.

Database Mirroring New for SQL Server 2005 Instant Standby Conceptually a fault-tolerant server Database Failover Very Fast … less than three seconds Zero data loss Automatic or manual failover Automatic re-sync after failover Automatic, transparent client redirect

Database Mirroring Hardware Impact to transaction throughput Works with standard computers, storage, and networks No shared storage components, virtually no distance limitations Impact to transaction throughput Zero to minimal, depending on environment / workload

Database Mirroring How it works Mirror is always redoing – it remains current Application Witness Commit 1 5 Principal Mirror 2 Not two-phase commit SQL Server SQL Server 4 2 >2 3 >3 Log Data Log Data

Witness and Quorum Witness Sole purpose of the Witness is to provide automatic failover To survive the loss of one server you must have at least three Prevents “split brain” Does a lost connection mean the partner is down or is the network down? To become the Principal, a server must talk to at least one other server

Witness Witness is an instance of SQL Server 2005 Single witness for multiple sessions Consumes very little resources Not a single point of failure Partners can form quorum on their own

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

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

Database Mirroring Setup Steps Ensure SQL 2005 is installed on both the principle & the mirror Server Setup Security (Endpoints) Prepare the mirror database Setup & Start the database mirroring session Optionally add a witness

SQL 2005 Database Mirroring Demo SQL 2005 Database Mirroring

Database States for Database Mirroring SYNCHRONIZING SYNCHRONIZED SUSPENDED PENDING_FAILOVER DISCONNECTED SYNCHRONIZING The mirror is lagging behind. This is the state when Mirroring is configured. SYNCHRONIZED The mirror database contains the same data as the principal database. Manual and automatic failover are possible only in the SYNCHRONIZED state SUSPENDED The mirror copy of the database is not available. The principal database is running exposed, without sending any logs to the mirror server instance. SUSPENDED is a "permanent" state. The only ways for a session to become SUSPENDED is to be explicitly suspended or encounter redo errors PENDING_FAILOVER This state is found only on the principal server instance when a manual failover has been issued but not yet accepted by the mirror DISCONNECTED The partner loses communication with the other server instance(s) (the other partner and the witness, if one exists).

Automatic Failover Automatic Failover requires the following conditions: Database mirroring running in synchronous mode The database must be in a synchronised state A witness must exist During Failover the following actions occur: The witness & mirror server agree the primary is dead, which puts the database into a suspend state If possible the database on the Primary server changes to a disconnected state The mirror finishes rolling forward and records the LSN The mirror database comes online When the principle returns, it becomes the mirror

Failover Solutions At A Glance Clustering & Mirroring both provide: Automatic detection and failover Manual failover Transparent client connect Failover Clustering System scope Certified hardware Fast failover No reporting on standby Single copy of database Database Mirroring Database scope Standard servers Fastest failover Limited reporting on standby Duplicate copy of database

Summary How many 9’s do you NEED? SQL 2000 potential downtime ~3 mins SQL 2005 potential downtime ~3 secs Remember to consider process too!

Feel free to contact us Craig Ryan cryan@sdg.com.au Andrew Gannon National Manager Database Services cryan@sdg.com.au Andrew Gannon Business Development Manager agannon@sdg.com.au (03) 9427-1477