Azure storage accounts have several options when creating them to define how the data within them is protected and made available in the event of hardware or even regional failure.

We looked in detail at storage accounts in Chapter 9, Exploring Storage Solutions, where we looked at different replication options such as locally redundant storage(LRS) and geo-redundant storage (GRS).

To recap, data in Azure is always replicated to ensure durability and high availability. Storage replication can be set during the creation of a storage account; however, you can change the type of replication later by using the Azure portal, PowerShell, or the CLI.

In the event of an outage of the region that contains your storage account, failover is not automatic. You must manually switch your secondary replica to be the primary. Note that because data is copied from one region to another asynchronously, that is, the data is copied to the secondary region after it has been written to the primary, there is still a chance, therefore, that some data could be lost if the outage happens before the data has had an opportunity to replicate.

It is also worth noting that, unlike some other data redundancy options, you do not have a choice as to which region your geo-redundant replica is stored in. Each region has its pair, and when enabling GRS or ZA-GRS, the Azure platform will use that paired region and cannot be changed.

When using regional replication, you can access the secondary endpoints for direct read-only access, but failover is automatic and cannot be manually triggered.

In the next section, we will see what availability options we have for SQL databases.

Understanding SQL database availability

Even when your databases are hosted in Azure, there is still a chance that failures and outages will occur. In the case of an outage (such as a total regional failure, which a natural disaster could cause, an act of terrorism, war, a government action, or a network or device failure external to the data centers of Microsoft), your data still needs to be accessible.

In Chapter 12, Creating Scalable and Secure Databases, we looked at database service tiers chosen when creating a SQL Server database – the General tier, Hyperscale tier, and Business Critical tier.

With the General and Hyperscale tiers, by default, data is replicated within a single region. However, it Is not regionally redundant. This is partly due to how data is protected within them. Essentially, data is stored in Azure storage accounts and therefore uses that underlying technology to spread and replicate data among physical disks. However, there is still only ever one database – as we can see in the following diagram:

Figure 14.4 – General and Hyperscale data replication

To create highly available SQL Server databases in Azure, you can use failover groups and active geo-replication. By default, the Business Critical tier creates a secondary replica, and with the Hyperscale tier, you can optionally create additional replicas.

Replicas in this sense are additional copies of the database and server. In other words, you essentially have two Azure SQL servers, each serving their copy of the database – as we can see in the following example:

Figure 14.5 – Business Critical tier replication

Replicas can be created within the same region or across regions. Of course, creating a replica within the same region only protects against Availability Zone loss, whereas building your database in another region provides full protection. Unlike an Azure storage account, when creating database replicas, you can choose whichever target region you prefer – this helps when designing solutions that want read-only copies of your database closer to a target audience.