oracle dbas deploying highly available sql server systems joe yong chief architect scalability...

Oracle DBAs Deploying Highly Available SQL Server Systems

Oracle DBAs Deploying Highly Available SQL Server Systems

Joe YongChief ArchitectScalability Experts [email protected]

About This Session

GoalsOverview of SQL Server 2005 High Availability featuresDrilldown on HA implementation strategies

Non-goalsDeep dive into SQL ServerChest thumpingMake you a HA expert

Pre-requisitesExperience as an Oracle DBA, Architect or Developer DBABasic experience in designing, deployment and managing database systems that require medium to high levels of availability

Agenda

What is High AvailabilitySQL Server 2005 HA overviewSolutions to common scenariosCase studySummary

What is High Availability

Uninterrupted usabilityA running server is not necessarily available

Is a factor of technology, people and processesOften measured as a percentage in “uptime” over 1 year

Eg. 99.999% uptime = 5.25 minutes downtime a yearShould includes both planned and unplanned downtime but many only measure unplanned

You may not own every part of the equation but if you have to specify your SLAExample

Online ordering system requires orders to be confirmed in 30 secondsAvailability is impacted by application scalability, network and databaseDon’t forget security impact on HA

Agenda

What is High AvailabilitySQL Server 2005 HA technologies

Hot StandbyFailover ClusteringDatabase Mirroring

Warm StandbyDatabase Mirroring – High Protection / Performance modeReplication Log Shipping

Cold StandbyBackup/restore

Online operations

Solutions to common scenariosCase studySummary

Failover ClusterFailover Cluster

* Inst1* Inst1

N+1: N Active, 1 Inactive N+1: N Active, 1 Inactive InstancesInstances

Inst2 *Inst2 *

* Inst1* Inst1

Multiple Active InstancesMultiple Active Instances

Inst2 *Inst2 *

* Inst1* Inst1

Inst3 * Inst3 *

N+I: N Active, I Inactive N+I: N Active, I Inactive InstancesInstances

Hot Standby – Automatic failoverProtects against local, limited disastersBuilt on Microsoft Server Clusters (MSCS)

Multiple nodes provide availability, transparent to clientSupports 2, 4, or 8 nodes depending on OS edition

Automatic detection and failoverRequires cluster certified hardware; see Windows Catalog: ClusteredSupports many scenarios: Multiple Active Instances, N+1, N+IUp to 25 SQL Server instances per cluster

NOT a load balancing solution

Microsoft Failover ClusteringOverview

Microsoft Failover ClusteringDetail

Geographically Dispersed Clusters

Mirror

Network

N1 N4N3N2

D3

D1

Storage Controller S1

D2

D4

Storage Controller S2

Site 1 Site 2

Mirror

Same functionality and behavior as “standard” failover cluster

Protects against local, total and extended disasters

Requires specially certified cluster hardware from qualified vendors

Requires guaranteed 500ms maximum round trip latency between nodes

SQL Server does not differentiate between standard and geo-cluster

Disaster Recovery Features

Failover Clustering

Local limited disasters

Local disasters

With geo-clusters

Extended disastersLimited

With geo-clusters

Rapid failover

Failure detection Automatic switchover

Specialized hardware

Secondary workload on standby (reporting)

Meta data support Performance impact None

Protect against storage failure

Locations Limited

High Availability Toolbox

Agenda


Hot StandbyFailover ClusteringDatabase Mirroring – High Availability mode

Warm StandbyDatabase Mirroring – High Protection / Performance modeReplication Log Shipping


Online operations


Database MirroringDatabase Mirroring

Database MirroringOverview

Hot StandbyProvides a fault-tolerant database

Building block for complex topologies

Database FailoverVery fast failover

Less than five seconds in most cases

Zero data loss

Automatic or manual failoverAutomatic re-sync after failover

Automatic, transparent client redirectWorks with standard certified servers, storage and networks

No location limitations

No shared components; two separate copies of data

MirrorPrincipal

Witness(optional)

Log

Application

SQL Server SQL Server

2

2

4

51

Data DataLog

3>2 >3

Mirror is always redoing – it remains currentCommit

Database MirroringHow does it work?

Only required for automatic failover; Just another instance of SQL Server 2005

Can serve multiple sessions

Prevents “split brain” scenarioIf partners do not see each other, is it due to network failure or server failure?

To become Principal automatically, a server must talk to at least one other server

Witness ONLY answers the question “Who do you see?”, does not promote a server to be Principal

Database MirroringWitness

Database MirroringHigh Availability mode

Safety Full; synchronous operationCommit when logged on Mirror

Allows automatic failover

No data loss

Database available whenever quorum exists

Formed by any two servers from the three; Principal, Mirror, Witness

Witness is present – automatic Failover

Database MirroringTransparent Client Redirect

SQLConnection object that targets a mirrored database

No application code change required

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 reconnectIf Principal is available, connectsIf not, client library automatically redirects connection to Mirror

If Principal is down upon first connect attempt, connection fails

Workaround via explicit coding or NLB type solution

Supports .NET and SNAC providers



Failover Clustering

Database Mirroring – HA mode


Local disasters

With geo-clusters


With geo-clusters

Rapid failover Failure detection Automatic switchover



With DB snapshot

Meta data support User DB only

Performance impact None Minimal ~ low


Locations Limited Unrestricted

Agenda



Warm StandbyDatabase Mirroring – High Protection / Performance modeReplicationLog Shipping


Online operations


Database MirroringHigh Protection mode

Safety Full; synchronous operationCommit when logged on Mirror

No automatic failover; manual failover only

Database quorum formed by Principal and MirrorIf Principal loses quorum, it stops servicing the database

Ensures high protection; database is never in ‘exposed’ state

No Witness present – no automatic failover

Database MirroringHigh Performance mode

Safety Off; asynchronous operationCommit when logged on Principal

No automatic failover; manual failover only

Possible data loss

If Mirror becomes unavailable; Principal continues workingIf Principal becomes unavailable; Mirror can assume workload

Manual failover to Mirror is required

No Witness present; no automatic failover


Failover Clustering


Database Mirroring – H P/P mode


Local disasters

With geo-clusters


With geo-clusters

Rapid failover

Failure detection Automatic switchover



With DB snapshot

With DB snapshot

Meta data support User DB only User DB only

Performance impact None Minimal ~ low Minimal


Locations Limited Unrestricted Unrestricted


Agenda



Warm Standby Database Mirroring – High Protection / Performance modeReplicationLog Shipping


Online operations


Transactional Replication

Requires consideration at design time; cannot just “flip the switch”High performance – latency measured in secondsSome (minimal) load on the serverCan be implemented at database or table levelFailover possible; custom designed solutionTwo types

Standard transactional replicationEasy to design, setup & manageSubscriber (standby) can be used for reporting

Peer-to-peer transactional replicationMulti-master model; schema is identical on all sitesSupports distributed applications with data partitioning; enables load balancingDoes not handle conflicts; design to avoid/prevent conflicts

Distribution Distribution AgentAgent

DistDistDBDB

Logreader Logreader AgentAgent


DistDistDBDB



DistDistDBDB


““West”West” ““East”East”

““South”South”

Peer-To-Peer Transactional ReplicationHow does it work?


Failover Clustering


Database Mirroring – H P/P mode

Transactional Replication


Local disasters

With geo-clusters


With geo-clusters

Rapid failover

Failure detection Can automate in application

Automatic switchover

Can automate in application



With DB snapshot

With DB snapshot

Meta data support User DB only User DB only Some

Performance impact None Minimal ~ low Minimal Low


Locations Limited Unrestricted Unrestricted Unrestricted


Agenda





Online operations


Backup transaction log, copy to secondary server, restore transaction log backup Failover is manual

Meta data management may be necessary

Read operations on secondary is permittedUsers are disconnected when log restore occurs

Can maintain multiple secondary serversOptional Monitor server

Records history and status of backup/restore jobs

May be setup to raise alerts when jobs fail

Log Shipping


Failover Clusterin

g

Database Mirroring

– HA mode

Database Mirroring

– H P/P mode

Transactional

Replication

Log Shipping


Local disasters

With geo-clusters


With geo-clusters

Rapid failover







With DB snapshot

With DB snapshot

With

limitations

Meta data support User DB only User DB only Some User DB only

Performance impact None Minimal ~ low Minimal Low Low


Locations Limited Unrestricted Unrestricted Unrestricted Unrestricted


Agenda

What is High Availability

SQL Server 2005 HA technologiesHot Standby

Failover ClusteringDatabase Mirroring – High Availability mode



Online operations

Solutions to common scenarios

Case study

Summary

Backup and Restore

Slowest recovery (but also simplest)Recommended as secondary or tertiary protection layerManual failure detection and switchoverData loss possibleRecommend maintaining active backups on disk; duplicate, archive and offsite backups on tapeVarious levels

Database – full, differential, partial, differential partial, copy-only

File & filegroups – “full”, differential

Transaction log

Backup and Restore

RESTORE VERIFY ONLYBackup media mirroringBackup and database page checksumsFine grained online repair

Online restorePiecemeal restorePage-level restore

Database backup does not block Log backupBackup/restore includes FullText dataCopy-only – via T-SQL only


Failover Clusterin

g

Database Mirroring

– HA mode

Database Mirroring

– H P/P mode

Transactional

Replication

Log Shipping

Backup / Restore


Local disasters

With geo-clusters


With geo-clusters

Rapid failover






With DB snapshot

With DB snapshot

With

limitations

With

limitations


User DB only

Performance impact None Minimal ~ low Minimal Low Low Low



Unrestricted


Agenda



Warm Standby Database Mirroring – High Protection / Performance modeReplicationLog ShippingDatabase Snapshot


Online operations


Online Operations

Backup/restoreFull online backup

Online piecemeal restore; undamaged data remains available

IndexingAllows create, drop and alter while users continue to access data

LOB datatype indexes not supported for online

Memory allocationsCPU affinity settingsDatabase snapshots

Database Snapshot

Not originally designed as a specific HA solution but works great in some situationsTurning a Database Mirroring mirror into a reporting serverIsolated historical data for report generationProtection in case of administrative, developer or user error; classic “Oops!” scenarioUses copy-on-write technique to reduce disk space consumption

mydbSnap – Read-Only Database SnapshotUSE mydbSnapSELECT (pages 4, 6, 9, 10, 14)

11

Page

22 33 44 55 66 77 88 99 1010 1111 1212 1313 1414 1515 1616

CREATE DATABASE mydbSnap AS SNAPSHOT OF mydb

mydb – Database

USE mydbUPDATE (pages 4, 9, 10)

44 99 101011 22 33 44 55 66 77 88 99 1010 1111 1212 1313 1414 1515 1616

Database SnapshotHow does it work?

Agenda

What is High AvailabilitySQL Server 2005 HA technologiesSolutions to common scenariosCase studySummary

1. Perform upgrades on the mirror, secondary, or subscriber

2. Switch rolesDatabase Mirroring Failover to the mirror

Log Shipping

Replication Redirect clients to subscriber

3. Perform upgrades on the original database server

Optional: Switch roles again

1.1. Backup principal log with no-recoveryBackup principal log with no-recovery2.2. Recover secondary Recover secondary 3.3. Re-direct clients to secondaryRe-direct clients to secondary

Rolling UpgradesIn three steps

Site Disaster Protection

Example ScenariosEarthquake, fire, or flood causes datacenter outage

SolutionsDatabase Mirroring to a secondary site

Optimized solution - Allows very fast failover times to the secondary site

Optionally add log shipping for additional site protection

Log Shipping to one or more secondary sitesBasic solution – requires additional effort for failover

Third-party geo-clustering solutions for data center storage level redundancy

Find SQL Server Always On reviewed solutions at the Microsoft Always On website: www.microsoft.com/SQL/AlwaysOn

http://www.microsoft.com/SQL/AlwaysOn

http://www.microsoft.com/SQL/AlwaysOn

Step 1: Restore Step 1: Restore database copy to database copy to mirror site with mirror site with no-recovery optionno-recovery option

Step 2: Step 2: Configure Configure communication communication endpointsendpoints

Step 3: Set the Step 3: Set the data protection data protection level and Start level and Start MirroringMirroring

Database Mirroring ConfigurationIn three steps

Database Query Workload Scale Out With Redundancy

ScenarioNeed for near real time reporting on a second server that can also be used for disaster recovery

Need for a tier of identical databases for scaling out application queries with ability to use any one of the database copies for disaster recovery

SolutionsTransactional Replication

Peer-to-Peer Replication

Putting It All Together

Database MirroringDatabase Mirroring

Hot Hot StandbyStandby

Warm Warm StandbyStandby

Logical Logical RecoveryRecoveryStandbyStandby

Log ShippingLog Shipping

Log Shipping Log Shipping With Restore DelayWith Restore Delay

ProductionProductionDatabaseDatabase

ReplicationReplicationDatabaseDatabaseScale OutScale Out

For QueriesFor Queries

Failover Failover ClusteringClustering

Failover ClusteringLocal server redundancy

Full server/instance protection

Database MirroringPrimary disaster site for databases

Reporting with Snapshot

Log ShippingAdditional disaster sites for databases

Logical recovery (with delay)

ReplicationDatabase reporting and read scale out with redundancy

Agenda

What is High AvailabilitySQL Server 2005 HA technologiesSolutions to common scenariosSummary

Summary

<<WiP>>

Resources

www.microsoft.com/sql/msdn.microsoft.com/sqlserver/www.microsoft.com/technet/www.scalabilityexperts.comwww.sqldev.netwww.sqlservercentral.com/

http://www.microsoft.com/sql/

http://www.msdn.microsoft.com/sql/

http://www.msdn.microsoft.com/sql/

http://www.microsoft.com/technet/

http://www.scalabilityexperts.com/

http://www.sqldev.net/

http://www.sqlservercentral.com/


Failover Clusterin

g

Database Mirroring

– HA mode

Database Mirroring

– H P/P mode

Transactional

Replication

Log Shipping

Backup / Restore


Local disasters

With geo-clusters


With geo-clusters

Rapid failover






With DB snapshot

With DB snapshot

With

limitations

With

limitations


User DB only

Performance impact None Minimal ~ low Minimal Low Low Low



Unrestricted


oracle dbas deploying highly available sql server systems joe yong chief architect scalability...

Documents