c
c

High Availability

Craig Ryan
National Manager Database Services
 › 
! 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
?

›    

Need to ask yourself:
! How long can we afford to be down?
! How much data can we afford to lose?

Availability = up/(up+down)

Downtime Downtime Downtime Downtime

Category % Uptime (Min/mth) (Hrs/mth) (Min/Year) (Hrs/Year)

  
 
















  



  




















  



   























 



   





























   



 [  ›   
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
 ]cc 
 
  
c  

! Database Object Level

! SQL Server Replication
! Database Level
! Log Shipping

! Both provide multiple copies

and a MANUAL fail over
 Log Shipping

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

Load Job Secondary

Primary SQL Server
SQLServer

opy Job
 
 
 á
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
 á
SQL 2000 Transactional Replication
 Failover Cluster

‰  
  
  
c 

! 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
 ›  c
c

Client Cs

SQL Server
Virtual
Server A Server Server B

Heartbeat
Cluster management

Hub Shared Hub

Disk Array

E F G
C,D C,D
SQL Server
 ›  c
c

Client Cs

SQL Server
Virtual
Server A Server Server B

Heartbeat
Cluster management

Hub Shared Hub

Disk Array

E F G
C,D C,D
SQL Server
 ]
    
! 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
!






! Clustering is not a method to load-balance

c  

    

 á
SQL 2000 Failover Clustering

c   
  c
  

So what¶s the best solution«.

« it depends
« On your business requirements

You can combine the SQL H.A options.

E.g. A/ Cluster with Log shipping
c
c
High Availability
 [  ›   
› c
c
! 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
 Failover Cluster

‰  
  
c
c

Further refined in SQL Server 2005

! More nodes
! Match operating system limits
! Unattended setup
! Support for mounted volumes (Mount oints)
! All SQL Server services participate
! Database Engine, SQL Server Agent,
Analysis Services, Full-Text Search, etc.
 Database Mirroring
á   


 c
c

! 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
! 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
 á    
?
 


Mirror is always
Application Witness redoing ± it
remains current
Commit
rincipal Mirror

1 5
2
SQL Server SQL Server

2 >2 4 3 >3

Log Data Log Data

 Witness
] 


! Sole purpose of the Witness is
to provide à
à
 failover
! To survive the loss of  server you
must have at least
 
! 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
 c 
! 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
   
! 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
á    c
c
1. Ensure SQL 2005 is installed on both the
principle & the mirror Server
2. Setup Security (Endpoints)
3. prepare the mirror database
4. Setup & Start the database mirroring session
5. Optionally add a witness
 á
SQL 2005 Database Mirroring
ác á   
! SYNCHRONIZING
! SYNCHRONIZED
! SUSpENDED
! pENDING_FAILOVER
! DISCONNECTED
 ›
  ‰  
! 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
 ‰  c 
 ›› 

! Clustering & Mirroring both provide:

! Automatic detection and failover
! Manual failover
! Transparent client connect

! Failover Clustering ! Database Mirroring

! System scope
! Certified hardware
! Fast failover
! No reporting on standby
! Single copy of database
! Database scope
! Standard servers
! Fastest failover
! Limited reporting on standby
! Duplicate copy of database
 c

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


Craig Ryan
National Manager Database Services
cryan@sdg.com.au

Andrew Gannon
Business Development Manager
agannon@sdg.com.au
(03) 9427-1477