SQL Server High Availability and Disaster Recovery using

AlwaysOn Availability Groups

Ionuţ Hrubaru: ionut.hrubaru@gmail.comBogdan Lăzărescu: lazarescu.bogdan@gmail.comDragoş Eşanu: dragos.esanu@gmail.com

Iaşi, 25.10.2014

Agenda

HA/DR concepts

SQL Server HA/DR technologies

AlwaysOn Availability Groups

Demo

HA/DR

What does it mean?

Business continuity management

Quantifying downtime: RPO/RTO

Planning

HA/DR

Disaster recovery (DR) involves a set of policies and procedures to enable the recovery or continuation of vital technology infrastructure and systems following a natural or human-induced disaster.

Business Continuity Plan

Policies, processes and procedures Possible options and decision-making responsibility

Human resources and facilities Information technology

PPT Process

People

Technology

High Availability

Minimize the impact of downtime Business impact SLA

𝐴𝑐𝑡𝑢𝑎𝑙𝑢𝑝𝑡𝑖𝑚𝑒𝐸𝑥𝑝𝑒𝑐𝑡𝑒𝑑𝑢𝑝𝑡𝑖𝑚𝑒

×100%

Number of 9’s Availability Percentage Total Annual Downtime

2 99% 3 days, 15 hours3 99.9% 8 hours, 45 minutes4 99.99% 52 minutes, 34 seconds5 99.999% 5 minutes, 15 seconds

High Availability

Planned vs. Unplanned Maintenance Downtime = direct & indirect costs ROI and opportunity cost

High Availability

For isolated server failuresWindows crash, RAID controller failure, SQL or Windows patch fails, C drive full, bad memory chip, wrong box unplugged

For widespread outagesData center power or network outage, domain controller failure, SAN failure, fire, quake, zombies in the data center

Disaster Recovery “Oops” Deletions

For human T-SQL errorsDELETE without a where clause, bug in stored procedure for updates, end user needing a restore due to human error

Source: brentozar.com

Technologies

Log Shipping

Pros and Cons

Pros Cons

Multiple servers Manual failover

Cheap Backup dependent

Reporting Data loss

Protection against user mistakes

Use case

DR

Easy configuration

Low cost

Larger RTO

Mirroring

Pros and Cons

Pros Cons

Automatic failover 2 servers (databases) only

Standard edition (sync) Secondary database inaccessible

Transparency Possible performance issues (sync)

Cheap (sync) Deprecated (2012)

Use case

HA (sync mode) – same datacenter

Easy configuration

Low cost

RPO/RTO close to zero

Replication

Pros and Cons

Pros Cons

Read-write secondary dbs Manual failover

Standard edition Complex setup

Multiple servers Performance (transactional)

Disconnected architecture – multi master (merge)

Use case

Scale out

Offline processing

It’s about making data available, not redundant

Failover Cluster

Pros and Cons

Pros Cons

Instance level protection Shared storage SPOF

Multi server cluster Expensive

Automatic failover Complex setup

Transparency to the application

Use case

HA

Typical HA/DR Topology

AlwaysOn

Features AlwaysOn Failover Cluster Instances (FCIs) AlwaysOn Availability Groups

Layers of protection Infrastructure (WSFC) SQL Server instance level (FCI) Database level (Availability Groups) Client connectivity (VNN => AG Listener)

Availability Groups

Multiple databasesScale out

Non shared storageAutomatic page repair

Pros and Cons

Pros Cons

Built upon mirroring Rather complex setup

Multiple databases Performance (sync)

Scale out

Use case

HA

DR

Scale reads

Comparison

High Availability and Disaster RecoverySQL Server Solution

Potential Data Loss (RPO)

Potential Recovery Time (RTO)

Automatic Failover

Readable Secondaries

AlwaysOn Availability Group - synchronous-commit Zero Seconds Yes 0 - 4

AlwaysOn Availability Group - asynchronous-commit Seconds Minutes No 0 - 4

AlwaysOn Failover Cluster Instance NA Seconds-to-minutes Yes NA

Database Mirroring - High-safety (sync + witness) Zero Seconds Yes NA

Database Mirroring - High-performance (async) Seconds Minutes No NA

Log Shipping Minutes Minutes-to-hours No Not duringa restore

Backup, Copy, Restore Hours Hours-to-days No Not duringa restore

Demo

Topology

Q&A

linkedin.com/groups/DBA-Lounge-4929632

Thank you!