Venture into the world of Azure Infrastructure, where design meets functionality. Harness your skills and gain mastery over complex cloud structures to ace the AZ-305 Designing Microsoft Azure Infrastructure Solutions exam!
Gauge your current knowledge
Gauge your current knowledge
When planning recovery for SQL Server databases in Azure, several built-in technologies help keep data available during failures. Failover clustering automatically switches operations to a backup server when hardware or software fails, while Always On availability groups maintain multiple synchronized copies of a database across different servers. Database mirroring provides high-performance asynchronous replication, and log shipping periodically moves transaction logs to a secondary system for recovery. For geographic protection, active geo-replication copies databases across regions asynchronously, enabling near real-time failover when a whole data center experiences an outage. Auto-failover groups simplify the failover process by automating the switch between primary and secondary databases, reducing manual steps during an emergency.
Azure Site Recovery (ASR) works alongside these SQL Server business continuity and disaster recovery (BCDR) technologies to meet specific recovery targets. The recovery time objective (RTO) measures how long the system can be down, while the recovery point objective (RPO) defines how much data loss is acceptable. Pairing ASR with Always On availability groups provides minimal data loss through asynchronous replication, making it suitable for high-performance environments. Failover clustering using Always On Failover Cluster Instances (FCI) shares storage between nodes and ensures zero data loss, though it requires more complex setup. Database mirroring and log shipping work well when the business can tolerate higher data lag, offering cost savings compared to synchronous replication options.
Azure Site Recovery creates recovery points using two types of snapshots. Crash-consistent snapshots capture the state of disks every five minutes but do not preserve data held in memory, making them suitable for most applications that can tolerate some data loss. App-consistent snapshots include in-memory data and pending transactions by using the Volume Shadow Copy Service (VSS) on Windows systems, ensuring databases remain consistent after recovery. App-consistent snapshots are essential for database workloads but require more processing power and can temporarily slow down the system.
Once replication is configured, testing the recovery process ensures it works when needed. The failover step switches operations to the Azure virtual machine, while the commit failover step finalizes the switch and begins using the backup system. When the primary site is ready again, failback moves operations back, which requires setting up a temporary process server in Azure to handle the reverse replication. Testing these steps regularly helps identify issues before an actual disaster occurs.
Applications that span multiple virtual machines require coordinated recovery to maintain data integrity. Multi-VM replication groups ensure all related VMs share the same recovery point, keeping the application consistent across machines after failover. However, grouping VMs together can impact performance because the system must wait for all VMs to sync before creating a recovery point. This feature should only be enabled when application consistency is critical, such as for multi-tier applications where all components must recover to the same point in time.
StudyCerts
StudyCerts