Presentation is loading. Please wait.

Presentation is loading. Please wait.

SQL Server High Availability Amit Vaid.

Similar presentations


Presentation on theme: "SQL Server High Availability Amit Vaid."— Presentation transcript:

1 SQL Server High Availability Amit Vaid

2 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

3 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

4 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

5 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

6 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

7 Demo SQL 2000 Log Shipping

8 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

9 SQL 2000 Transactional Replication
Demo SQL 2000 Transactional Replication

10 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

11 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

12 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

13 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!

14 SQL 2000 Failover Clustering
Demo SQL 2000 Failover Clustering

15 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

16 SQL Server 2005 High Availability

17 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

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

19 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

20 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

21 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

22 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

23 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

24 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

25 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

26 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

27 SQL 2005 Database Mirroring
Demo SQL 2005 Database Mirroring

28 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).

29 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

30 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

31 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!

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


Download ppt "SQL Server High Availability Amit Vaid."

Similar presentations


Ads by Google