Dr and ha solutions with sql server azure

Disaster Recovery and High
Availability solutions with
SQL Server Azure
Montreal SQL Saturday
Prepared by Michelle Gutzait

WHOAMI?
gutzait@Pythian.com
SQL Server Consultant@ www.pythian.com
 24/7 Remote DBA services
© 2013 Pythian2

The environment
• OLTP/ DW?
• Availability? 24x7?
• Data loss and SLA?
• Local/hosted?
• SQL Server version and edition?
• Storage?
• Number of databases?
• Sizes of databases?
• Volume of transactions?
• Volume of reports?
• Backup strategy?
• Etc…

Problems?
• Performance issues
• Locks/blocks/deadlocks
• Application timeouts
• Backups failing
• Data updates VS reports
• Fragmented indexes
• Previous Database corruption
• Restore took too long
• Application bugs causing logical
corruption
• Long downtime on maintenance

HA and DR solutions
Primary and secondary environments can be:
• Only on-premises
• Only in Azure
• Hybrid (both on-premises and in Azure)
© 2013 Pythian6

Before Azure…
© 2013 Pythian8

Backups
• Full backup
• Differential backup
• T-Log backup
• Filegroup backup
• Filegroup Differential

Backups strategy for DR
• How long is the restore?
• Where are the backup files?
• What’s the affordable downtime?
• How much data loss is acceptable?

Log Shipping
• Replica of the entire database
• Synchronized to X minutes ago
• Backup and restore the t-logs
• Secondary can be:
– Read-only
– In recovery mode

Log Shipping - Pros
• Verification of production backups
• Lag to protect from accidental changes
(ex: protection during monthly/weekly
releases)
• Any change in DB is replicated
automatically, including DDL
• Multiple secondaries are allowed
• Read-Only replica
– Good for reporting
– Data can be read at standby server when DB is not
restoring
– CHECKDB, Fragmentation checks on secondary

Log Shipping - Cons
• X minutes data loss
• No automatic failover (can be automated)
• No easy failback (Log Shipping needs to be
recreated)
• DB Corruption may be replicated
• Database level replication, not instance
• T-log backup files can be large if there is a high
volume of transactions
• Database needs to be in FULL recovery model
• Same SQL Server version for read-only replica
• Users will be disconnected on DB restore
– Automatically
– Not automatically
• No particular indexes can be created for the
reports

Database Mirroring
• Replica of the entire database
• Synchronization
– Synchronized (High Safety)
• With or without a witness
– A-synchronized (High Performance)

Database Mirroring - Pros
• Real-time or close-to-real-time replica
• Any change in DB is replicated
automatically, including DDL
• Can implement Database Snapshots on
replica for reporting
• Corruption not being replicated
– SQL 2008+ page corresponding to a corruption is
retrieved from the replica/mirror and repaired,
transparently
• Easy failover and failback
• Automatic failover with a witness
– Faster failover than Clustering
• Reference to secondary instance in
connection strings

Database Mirroring - Cons
• Secondary cannot be used for reporting
– Can use Database Snapshot
• Sensitive to network bandwidth
– And volume of transactions
• A-synchronous mode - only in ENT Edition
• Witness - only in ENT Edition
• Deprecated in future releases
• Replication on the database level, not
instance
• Only one mirror allowed per database
• A bit more complicated if instances not in the
same network or Domain

Database Snapshot
• Static read-only copy of the
database
• Snapshot file grows when pages
modified
• On same instance as the original
database

Database Snapshot - Pros
• Great for reporting
– Non real-time data
• Great for DR
– Non real-time data
• Can be created on a mirrored replica
• Corruption will be kept if at page-level
• Created in less than a second
• Read –only operations such as DBCC or
index fragmentation
• Can be backed up

Database Snapshot - Cons
• Non real-time data
• Requires maintenance
– Multiple snapshots
– Add and remove
• Databases cannot be dropped if there is a
snapshot
• Snapshot cannot be dropped if there are
users
• No particular indexes can be created for
the reports

Replication
• Object-level replication
– Row level
– Column level
• Three types
– Snapshot
– Merge
– Transactional
• With updatable subscribers
• Peer-to-peer
• Transaction being replicated

Replication - Pros
• Partial replication
– Saving space and time
– Security
• Possibly different schema and different
indexes on secondary
• Great for reporting, users not disconnected
• Corruption not transferred
• Can configure a lag, protecting from
accidental data changes
• Secondary database can be backed up

Replication - Cons
• Management and troubleshooting
complexity
• All replicated tables require a Primary Key
• Database level replication, not instance
• More physical hardware required with
heavy IO throughput
• Some latency, possible data loss

Cluster
• Instance-level HA/DR
• High Availability with local cluster
• Plus Disaster Recovery with Geo-
Cluster
• 2 or N+1 nodes, M instances
• One instance can failover to different
nodes
• SQL Server has one virtual name

Cluster - Pros
• Failover transparent to applications
• Automatic failover on hardware or
OS failures
• Fast failover (only service restart)
• Easy upgrades and patches
• Can add nodes seamlessly
• Manual failover (ex: performance
reasons)

Cluster - Cons
• No protection from disk failure
• Only 2-node cluster for Standard
Edition
• More maintenance than a stand-
alone
• More expensive than a stand-alone
• There is no replica of the database
for reporting

Always
OnAvailability
Groups
• A mix of Failover clustering and
Database Mirroring
• Does not require shared storage
• Instances are not clustered
resources
• Database level replication
• Group of databases failing over
together
• Read-only or non-readable replicas
• Automatic failover
• Different sync modes
• Different failover rules
• Built-in Load balancing

Dr and ha solutions with sql server azure

Other solutions – not SQL Server,
not Azure
• VM replication
• SAN or storage replication
• 3-rd party tools
• Etc….

Architecture design – so far
Be creative….
Node A Node B
Instance A
Node N
Instance B
Passive
Instance C
Cluster

Other solutions – for Azure VMs
• Service healing for cloud services and
Failure recovery detection for the Virtual
Machines
– keep VM available even when there are problems
– VM proactively moved to new nodes
– VM may restart
– IP address of the VM does not change
• Azure Site Recovery
– Hyper-V replication
• Geo Redundant Storage (GRS) for
Windows Azure
– Locally or zone redundant
– Three copies of your data
– http://blogs.msdn.com/b/windowsazurestorage/archive/2011/09/15/in
troducing-geo-replication-for-windows-azure-storage.aspx

Cloud (Azure) only HA/DR solutions - examples
• Built-in Always On Availability Groups
© 2013 Pythian35
Within same region
Different region

Cloud (Azure) only HA/DR solutions - examples
• Database mirroring
© 2013 Pythian36
Same region
With Domain Controller
Same region
Using certificates
Different region

Connect an on-premises network to
a Microsoft Azure virtual network
© 2013 Pythian40
https://technet.microsoft.com/en-us/library/dn786406%28v=office.15%29.aspx

Or…. Point-to-Site VPN
© 2013 Pythian41
http://blogs.technet.com/b/francesco_diaz/archive/2013/05/14/implementare-uno-
scenario-ibrido-con-sql-server-e-windows-azure-point-to-site-vpn.aspx

Follow the steps
• On-premises Define and create an on-premises
network that requires a route to the Azure virtual network
and a VPN gateway device.
• Microsoft Azure Create an Azure virtual network with a
site-to-site VPN connection via the Azure Management
Portal.
• On premises Configure your on-premises hardware or
software VPN gateway to terminate the VPN tunnel,
which uses Internet Protocol security (IPsec).
© 2013 Pythian42

Thank you!
gutzait@Pythian.com

Dr and ha solutions with sql server azure

Recommended

More Related Content

What's hot (20)

Similar to Dr and ha solutions with sql server azure (20)

More from MSDEVMTL (20)

Recently uploaded (20)

Dr and ha solutions with sql server azure