20
5 COMMON HIGH AVAILABILITY MISTAKES SQL Server Webcast Michael K. Campbell
5 COMMON HIGH AVAILABILITY MISTAKES
SQL Server Webcast
Michael K. Campbell
Michael K. Campbell Independent Consultant
Former DBA and Database Developer
Author, Contributing Editor, Presenter
Contact web: http://www.overachiever.net
email: [email protected]
twitter: AngryPets
5 Common HA Mistakes
In this Webcast
High Availability
Common HA Mistakes
Goal / Take-Away:
What you can do to avoid mistakes.
High Availability
High Availability Defined: Pro-Active Disaster Recovery
HA Options / Technologies: Log Shipping / Mirroring
Replication / SAN Replication
Clustering / Virtualized Nodes
Etc.
Which Option is Best? ANSWER: Success is NOT a function of which
technology you use.
5 Common HA Mistakes
1. Confusing HA and DR
2. ‘House-Boating’
3. Thinking Only of Data
4.
5.
HA = Highly Available Data
But what if your data is bad?
How quickly does it become bad ‘everywhere’?
Once it’s bad everywhere, then what?
HA is useless without GOOD data.
HA doesn’t usually address data quality.
It can even HINDER restoring data quality.
Common High Availability Mistake #1
MISTAKING HA as a Replacement for DR
Example
Juggling Flaming Chainsaws, Kittens, and Loaded (Sawed-Off) Shotguns.
Widgets Database
Mission Critical System.
Highly-Available – using Clustering and Log Shipping.
Tracks Inventory Levels for Products.
Products Sold Online OR through Call Center.
Not ready for Developers A and B.
Developers
Dude. Don’t stress. I read about this
once. We just need to run a ROLLBACK
or something...
!!!!
Developers
HA Location
Call Center
Web Site
Rollback?!?
HA Location
Safe Data
Developers
HA Location
Call Center Inventory = 0
Web Site Inventory = 0
Receiving +3,312 different
products
Dude?!? DBA
HA Location
Recovery Options Failover the Cluster?
Pointless.
Failover to an HA Location? Pointless, unless:
Synchronization Delay? Data Loss.
Recover Database? Point In Time Restore?
Data Loss – All operations AFTER the UPDATE.
Recover a Copy of the DB? Headache
Potential for Data Loss
http://www.flickr.com/photos/lastbeats/473632210/
Common High Availability Mistake #2
HOUSE-BOATING
High Availability and House-Boats
Example: Secondary Reporting Servers Commonly needed.
Commonly ‘bundled’ with HA Solutions.
Example: Log Shipping Highly Versatile HA Solution.
Can Delay Application of Log Files/Updates.
STANDBY.
Read Only / Reporting Databases Seems like the best of both worlds…
The Problem with House-Boats
http://www.flickr.com/photos/salim/2183984577/
There’s More to High Availability than DATA Making data available is core to HA But you NEED a viable environment
Otherwise, data is inaccessible / non-available
Considerations Hardware Capacity / Capability Server Services, SPNs, Access to Resources Encryption Keys, Custom Errors, Maintenance Plans Connection Strings, Ports, and Firewalls Application Security, Delegation, and Access User Permissions / Logins, Authorization Configuration / Settings, Performance Tweaks
Common High Availability Mistake #3
THINKING ONLY OF DATA
Common High Availability Mistake #4
FAILURE TO TEST REGULARLY
Not Testing Regularly
Don’t LOOK like an idiot
Don’t BE an idiot.
Regular Testing
Ensures that HA systems actually WORK.
Ensures that your environment hasn’t hosed you.
Ensures that you have the skills to ‘fail over’.
Common High Availability Mistake #5
FAILURE TO DOCUMENT
Documentation IMPLIES Testing
Viable Documentation only comes with testing
Viable Documentation only STAYS viable with continued testing.
Documentation IMPLIES Skills / Knowledge
Viable documentation REQUIRES understanding and skills need to recover from an emergency.
Documentation = Bus Factor You won’t always be there
With GOOD documentation, you won’t NEED to be there
Good Documentation
Good Documentation Starts with SLAs: Acceptable Down-Time Acceptable Data Loss
Documents More than Just Processes Includes Environmental Details / Credentials
Sealed Envelope Approach (Built-In Post Mortem)
Outlines / Defines Escalation Plans Provides Contact Information:
Management Vendors Other Admins / Resources
Avoiding Mistakes / Disasters
Take-Away / Things You Can Do:
Test Regularly
Keep Documentation Up to Date
