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.
Cosmos DB Implementation On Cosmos DB, geo-replication has been designed in a way that makes it trivial to activate and start using. You can go through the Azure Portal or through the Azure PowerShell, pick any region around the world where Cosmos DB is running and start the geo-replication process. On the portal you can also select the order of preference for failover and do a manual failover if you want to run a test.
Application Configuration To implement the read-only queries capability in your application, Microsoft has added support for this feature in all the Cosmos SDK libraries. The only thing that is necessary, is providing the global endpoint for your database (which you can get from the portal) and then the regions where you want to read the data from in order of preference. Note that this setting is not the same as failover. If your database does a failover (manual or automatic) but you don't specify the read preferences, your application will still connect to your failover region to continue doing read-write operations. Here's an example of setting the read region preferences in C#:
// 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(
https://mycosmosdb.documents.azure.com:443/,
"xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx",
connectionPolicy);
// test the connection
await docClient.OpenAsync();
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!
No Comments Yet
Let us know what you think