Cosmos DB Geo-replication - SQL on the edge episode 14
As Microsoft Azure's NoSQL service offering, Cosmos DB has received a lot of investment and development effort. Microsoft considers Cosmos as a "ring zero" service, which means that it is available by default from all regions as soon as they open for public usage. Considering its global availability, it only makes sense that the Cosmos team considered geo-replication capabilities from the very beginning and it wasn't just something added on to the service after the fact. What is geo-replication? Geo-replication is the process of keeping multiple copies of a database synchronized over large geographical distances. This is not high availability where we usually have copies of the database in the same data center or independent data centers that are close to each other. With geo-replication, we can have one copy of the database in the East coast of the USA replicating another copy in the West coast across the entire country. We can even replicate from the East coast of the USA all the way to the Tokyo Azure region if we want! Geo-replication therefore can be thought of as mainly a disaster recovery feature but it also opens up other interesting scenarios:
- Reducing read latency: you can place read copies of the database close to users locations.
- Graceful DR Degradation: if you have multiple geo-replicated regions you can set priorities to failover first to a region close to your main user base, then another a bit further and so on.
- Data Sovereignty: Cosmos DB offers geo-fencing by allowing the user to specify the failover regions. For example, if your data is not allowed to leave Canada, then you can setup your database to only permit failover between Canada Central and Canada East. This way, even in the event of a disaster, you know that you are compliant with your regulatory requirements.
// create a connection policy object
ConnectionPolicy connectionPolicy = new ConnectionPolicy();
//set the proper regions
connectionPolicy.PreferredLocations.Add(LocationNames.CanadaCentral); // first preference
connectionPolicy.PreferredLocations.Add(LocationNames.CanadaEast); // second preference
// initialize connection with your endpoint, your access key and the policy object we just created
DocumentClient docClient = new DocumentClient(
// test the connection
Demo Now that we have a good understanding of Cosmos DB's geo-replication, let's check out a demo of setting up the geo-replication on the Azure Portal and test the impact of using a closer read-only copy of the database for lower latency queries. Let's check it out!