Understanding Azure Service Level Agreements and the Resource Requirements Part 3 – Azure SQL

Achieving High Availability and Uptime with Azure SQL Databases

Introduction

Reliable, high-performance databases are essential for modern applications, and uptime is critical for maintaining business continuity. Azure SQL Database is built with high availability in mind, incorporating features like geo-replication, auto-failover groups, and built‑in redundancy that help deliver SLAs of up to 99.99% uptime. However, achieving such performance involves understanding and implementing specific deployment practices.

In this post, we explore how Azure SQL Database’s SLA is achieved through its high availability features. We will discuss the key requirements—such as geo-replication and auto‑failover groups—that help protect your database service against outages. You’ll also find practical, step‑by‑step implementation examples using both the Azure Portal and Bicep, giving you a comprehensive blueprint for building a resilient SQL Database environment.

Focus Areas

  • High Availability through Built-in SQL Database Features:
    Understand how Azure SQL Database meets its SLAs using features like automatic backups, geo-replication, and availability groups that are natively integrated into the service.

  • Key Deployment Requirements for Resiliency:

    • Geo-Replication:
      Extend your database across regions to ensure data is available even if one region experiences downtime.
    • Auto-Failover Groups:
      Configure automatic failover between primary and secondary databases to maintain continuity during planned or unplanned events.
    • Database-Specific Best Practices:
      Learn how proper configuration (such as performance tiers and redundancy settings) directly influences the SLA achievement.

Example Implementation

A. Using the Azure Portal

  1. Create a SQL Server and Database:

    • Step 1: Sign in to the Azure Portal and select Create a resource. Search for SQL Database.
    • Step 2: In the SQL Database creation wizard, fill out the basics:
      • Subscription, Resource Group, & Database Name: Provide appropriate values.
      • Select a SQL Server: Either choose an existing one or create a new server with a unique name, admin credentials, and a desired region.
      • Compute + Storage: Choose an appropriate service tier (e.g., Business Critical for high availability).
  2. Configure Geo-Replication:

    • Step 3: After your SQL Database is deployed, navigate to the SQL server hosting it.
    • Step 4: Under the Geo-Replication settings, click on Add secondary. Select a secondary region where you want your database to be replicated.
    • Step 5: Review the settings and create the replication. This process ensures that your database’s data will be available even if your primary region becomes unavailable.
  3. Set Up an Auto-Failover Group:

    • Step 6: Return to the SQL server’s overview and select Failover groups.
    • Step 7: Create a new failover group, add your primary and secondary databases, and configure the automatic failover policy.
    • Step 8: Save the configuration to enable automatic failover in the event of an outage.

B. Using Bicep

Below is a sample Bicep template that deploys an SQL server, a database, and configures geo-replication and an auto-failover group.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
// Parameters for SQL server and database deployment
@description('Name of the Primary SQL Server')
param sqlPrimaryServerName string = 'mySqlServer-AUE'

@description('Name of the Secondary SQL Server')
param sqlSecondaryServerName string = 'mySqlServer-AUSE'

@description('Name of the SQL Database')
param sqlDbName string = 'myDatabase'

@description('Location for primary resources.')
param location string = resourceGroup().location

@description('Admin username for the SQL Server')
param adminUsername string = 'azsqladmin'

@description('Admin password for the SQL Server')
@secure()
param adminPassword string

@description('Secondary location for geo-replication')
param secondaryLocation string = 'australiasoutheast'

// Deploy the Primary SQL Server
resource sqlServerprimary 'Microsoft.Sql/servers@2024-05-01-preview' = {
  name: sqlPrimaryServerName
  location: location
  properties: {
    administratorLogin: adminUsername
    administratorLoginPassword: adminPassword
  }
}

// Deploy the Secondary SQL Server
resource sqlServersecondary 'Microsoft.Sql/servers@2024-05-01-preview' = {
  name: sqlSecondaryServerName
  location: secondaryLocation
  properties: {
    administratorLogin: adminUsername
    administratorLoginPassword: adminPassword
  }
}

// Deploy the primary SQL Database
resource sqlDatabase 'Microsoft.Sql/servers/databases@2024-05-01-preview' = {
  parent: sqlServerprimary
  name: sqlDbName
  location: location
  properties: {
    collation: 'SQL_Latin1_General_CP1_CI_AS'
    maxSizeBytes: 2147483648 // 2GB for sample purposes
  }
  sku: {
    name: 'S0'
  }
}

// Create a Failover Group for automatic geo-replication
resource failoverGroup 'Microsoft.Sql/servers/failoverGroups@2024-05-01-preview' = {
  parent: sqlServerprimary
  name: 'myfailovergroup'
  properties: {
    readWriteEndpoint: {
      failoverPolicy: 'Automatic'
      failoverWithDataLossGracePeriodMinutes: 60 // 1 hour minimum
    }
    partnerServers: [
      {
        id: resourceId('Microsoft.Sql/servers', '${sqlSecondaryServerName}')
      }
    ]
    databases: [
      sqlDatabase.id
    ]
  }
}

Deployment Instructions:

  1. Save the above Bicep file as sqlDatabaseHighAvailability.bicep.

  2. Open your terminal and log in:

    1
    
    az login
    
  3. Deploy to your resource group:

    1
    2
    3
    
    az deployment group create \
      --resource-group MyResourceGroup \
      --template-file sqlDatabaseHighAvailability.bicep
    

Note: The above template assumes that a secondary SQL server (with a corresponding name in the secondary region) is available. In a full implementation, you would include both the primary and secondary SQL server deployments and then configure the failover group.

Conclusion

Achieving high availability for your SQL Database is critical to maintaining the reliability and performance levels that modern applications demand. By leveraging Azure SQL Database’s built‑in high availability features—such as geo‑replication and auto‑failover groups—you can create deployments that adhere to SLAs as high as 99.99% uptime. Whether you choose the comprehensive, guided steps available within the Azure Portal or prefer the automation and consistency of Infrastructure-as-Code with Bicep, the strategies detailed in this post provide a solid foundation for resilient database design.

Learn More