Automating multi region cosmos db account to be availability zone redundnant.

Introduction: Azure is the public cloud that offers CosmosDB as a resource for storing documents. This service is the equivalent of a global database for organizations that want to store semi-structured data. When the CosmosDB is provisioned as a singleton instance, it is hosted in a single region with read and write capabilities. This is made zone –redundant when there are multiple instances of the CosmosDB server each in separate zones so that if one fails, another can take over. All the instances from these zones behave the same way and there is no data loss between failovers. When the CosmosDB is provisioned in multiple regions, some instance can participate to be read-only while others can be provisioned to be write-only. It is possible to write to any one of the regions capable of taking writes and be able to read it from a read only region. Provisioning such a multiple region account to be zone-redundant requires each of the regions to be zone-redundant. This article explains the steps to do so and the considerations to be made.

Description: The difference between migrating a single region account to a zone redundant formation and a multiple region account that is migrating to its zone-redundancy is that those other regions may not all behave the same way. They may work in read only or read-write modes and the account may display them in a list of regions corresponding to each of the sections titled Locations, Read Locations, and Write Locations in the summary information of its account. 

Powershell is a scripting language suitable for automations although it is not the only way for automating the migration of accounts from zonal to zone-redundant configurations. This example is described with the help of Powershell. The Powershell command to specify zone redundancy to the account takes only the LocationObject parameter for this purpose. The LocationObject can enumerate all the regions that the CosmosDB is hosted on but it does not differentiate between read and write regions. There are no other parameters or options to specify separate lists for read locations and write locations so it may come across as difficult to differentiate between the regions in the consolidated list.

Fortunately, the configuration is usually none or all for writes. This means that a single region will take write requests from the clients, or all the regions can be configured to take write requests. The latter is specified with the help of a boolean variable for the whole account and is represented at the same level as the Locations Object on the account. Specifying this flag implies that there are no read-only regions and if it is absent, there is only one region that is write while all the others are read only. It is possible to have any write regions as well as many read regions. 

This makes the automation to migrate an account to zone redundancy easy by starting with a Location Object that has only one region as write-only even if it not zone-redundant and taking all the other regions incrementally with the redundant zone option specified. Finally, the conversion of the single write-region can be migrated to zone-redundant formation in the same way as for a single region account. If the boolean option for all regions to be write based was originally specified, it can be added back to the account.

Testing for this fix is just as easy as the automation because we have either all the cases covered under three categories -  single, mixed and all regions. Ensuring that there are no regions that are read-only is guaranteed because a CosmosDB is never provisioned without one write region. Lastly, it must be called out that specifying zone redundant option on regions may throw an error if the region is not removed and added back.  This fits in nicely with the steps that have been taken.