Today we are excited to share the preview for account failover for customers with geo-redundant storage (GRS) enabled storage accounts. Customers using GRS or RA-GRS accounts can take advantage of this functionality to control when to failover from the primary region to the secondary region for their storage accounts.
Customers have told us that they wish to control storage account failover so they can determine when storage account write access is required and the secondary replication state is understood.
If the primary region for your geo-redundant storage account becomes unavailable for an extended period of time, you can force an account failover. When you perform a failover, all data in the storage account is failed over to the secondary region, and the secondary region becomes the new primary region. The DNS records for all storage service endpoints – blob, Azure Data Lake Storage Gen2, file, queue, and table – are updated to point to the new primary region. Once the failover is complete, clients can automatically begin writing data to the storage account using the service endpoints in the new primary region, without any code changes.
The diagram below shows how account failover works. Under normal circumstances, a client writes data to a geo-redundant storage account (GRS or RA-GRS) in the primary region, and that data is replicated asynchronously to the secondary region. If write operations to the primary region fail consistently then you can trigger the failover.
After the failover is complete, write operations can resume against the new primary service endpoints.
Post failover, the storage account is configured to be locally redundant (LRS). To resume replication to the new secondary region, configure the account to use geo-redundant storage again (either RA-GRS or GRS). Keep in mind that converting an locally-redundant (LRS) account to RA-GRS or GRS incurs a cost.
Account failover is supported in preview for new and existing Azure Resource Manager storage accounts that are configured for RA-GRS and GRS. Storage accounts may be general-purpose v1 (GPv1), general-purpose v2 (GPv2), or Blob Storage accounts. Account failover is currently supported in US-West 2 and US-West Central.
You can initiate account failover using the Azure portal, Azure PowerShell, Azure CLI, or the Azure Storage Resource Provider API. The process is simple and easy to perform. The image below shows how to trigger account failover in the Azure portal in one step.
As is the case with most previews, account failover should not be used with production workloads. There is no production SLA until the feature becomes generally available.
It’s important to note that account failover often results in some data loss, because geo-replication always involves latency. The secondary endpoint is typically behind the primary endpoint. So when you initiate a failover, any data that has not yet been replicated to the secondary region will be lost.
We recommend that you always check the Last Sync Time property before initiating a failover to evaluate how far the secondary is behind the primary. To understand the implications of account failover and learn more about the feature, please read the documentation, “What to do if an Azure Storage outage occurs.”
For questions about participation in the preview or about account failover, contact xstoredr@microsoft.com. We welcome your feedback on the account failover feature and documentation!