Date post: | 01-Jul-2015 |
Category: |
Technology |
Upload: | codecampiasi |
View: | 151 times |
Download: | 1 times |
SQL Server High Availability and Disaster Recovery using
AlwaysOn Availability Groups
Ionuţ Hrubaru: [email protected] Lăzărescu: [email protected]ş Eşanu: [email protected]
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!