Replication keeps copies of data in more than one place. If a storage account or region fails, another copy can help keep an application available or support recovery. Copies closer to customers can also make reads faster. The useful question is not just “Do I have a copy?” but “Where is it, how current is it, and how will people reach it?” section 9.4.1 section 10.5.1
Replication operates at different levels. Azure Storage is replicated at least three times within a region by default. For a redundant application spanning regions, replicated Azure SQL databases can keep data available alongside traffic routing and healthy virtual machines. Those application components still need to be planned together: a second database alone does not route a customer’s request. section 1.3.2 section 1.2.3
Choose the form that fits the data and the failure you are preparing for:
- Azure Storage object replication copies selected blobs between containers in different storage accounts. The accounts can be in different regions for disaster recovery or to place content nearer readers. It runs asynchronously, in near real time, rather than making every copy instantaneous. section 9.4 section 9.4.1
- Azure SQL Database geo-replication continuously copies a primary database to a readable secondary in another region. Active Geo-Replication supports manual failover and up to four readable secondaries; auto-failover groups add managed failover and listener endpoints. section 10.5.1 section 10.5.2
- Azure Cosmos DB multi-region replication places data in configured regions, with a failover priority for each. Zone redundancy can add protection within a region, but extra regions increase storage and request-unit costs; poorly configured replication can also increase write latency. section 11.1.2 section 11.1.3
Keep digital books available
Suppose customers need access to digital books even when the storage account serving them has a problem. Create a destination storage account and container. Enable versioning and the change feed on the source account, and versioning on the destination. Then create an object-replication policy naming the source and destination accounts and containers. Putting the destination in another region also prepares for a regional disruption; putting it nearby does not provide that same geographic separation. section 9.4 section 9.4.1
C:/> az storage account or-policy create --account-name banningstoragereplica --resource-group BanningRG --source-account banningstorage --destination-account banningstoragereplica --source-container bannedbooks --destination-container booksreplica --min-creation-time '2021-09-01T00:00:00Z'
The Azure CLI listing shows the policy command and the source and destination account and container parameters used in the storage example. section 9.4
For a database-backed ordering system, create a secondary Azure SQL server before creating its database replica. Decide whether manual failover is acceptable or an auto-failover group is needed. Budget for the choice: geo-replication can raise Azure SQL costs, just as additional Cosmos DB regions raise theirs. Replication is valuable, but each extra copy has a job—and a bill. section 10.5.1 section 10.3.1 section 11.1.3
