The title is self-explanatory. Would be awesome if changes to a DocumentDB in one DC gets automatically propagated to the other ones.
We have just released multi-region database accounts as generally available. See more information here: https://azure.microsoft.com/documentation/articles/documentdb-distribute-data-globally/
Azure DocumentDB Team
Baris Saydag commented
Hi! Are there any plans for multi-master replication in CosmosDB (and Mongo interface to it)? Amazon AWS DynamoDB has it. When can we see it in Azure Cosmos?
What's the global replication status of mongodb api protocol?
Are these read-only replicas or do they support multi-master scenario?
Praneet Loke commented
It has been more than a year since the status of this feedback was updated. Any news on the addition of this feature to DocDB?
Praneet Loke commented
This...would be awesome!
Seriously, Azure is lacking a solution for geo-replicated storage in the NoSQL technology. Azure Storage tables fell short. I know that the Azure Marketplace has Cassandra through Datastax but I don't want to do that. I'd like to provision a DocumentDB account in multiple regions and have my collections and DBs synced between them. It could even be a property of the DB/collection that one creates, as to whether it needs to be synced with other regions.
Or....give us Cassandra through Azure just like DocumentDB. That would be a good compromise while you work on this feature for DocumentDB. ;)
@Artem thanks for reaching out. This is currently still under review, so it is safe to say this will not be delivered in the "nearest future".
in terms of a work-around, we have customers today that use a double write system to store records in two databases in two different regions, either writing directly to the remote acc or, using a queueing system to async write to the remote region.
we will update this thread as soon as there is a change on the status of this item.
Artem Mitrokhin commented
I know, It has been a while since you asked additional questions related to the Geo-Replication. We would be highly interested a in master-***** replication across selected secondary data centers to scale-out reads in replicas.
Are there any plans to add it in the nearest future? Is there an appropriate workaround for it except of moving to IaaS using another document database?
James Jones commented
Ryan, would it be feasible to scale out writes? In other words, a more decentralized model? Use session consistency (aka "read my writes") to maintain affinity with a given node? I understand this might not be feasible depending on how the system is currently architected. But this would be a dream if you could get it done.
I think 30 seconds would be a reasonable cap for replication latency/maximum staleness. I know Amazon's non-geo replicated service has gotten away with a 30-second time-to-full-consistency, so I think 30 is a safe number for geo replicated.
REPLICATE ALL THE REGIONS!
Is the ask on providing Geo-Replication for DR purposes? i.e. If a DC disappeared or failed you wanted to continue business in another location?
Could you survive with having a Backup / Restore solution that allowed you to remotely restore from backup in the event of a DC failure?
do you just want replication to region 2 for DR purposes, or to scale-out reads by having readable replicas in the second region?
is async master - ***** replication good enough for your use cases?
what is an acceptable latency between a write landing in the primary and it showing up in the secondary?
do you need to be able to configure where the secondary is, or are you ok with the default "sister" region?
do you need more than one secondary location?
Mitch Denny commented
Yep - and the Document DB already has to concept of eventual consistency so its a good fit.
Daniel Chambers commented
I think this should work in a similar vein to the geo-replication in Azure Storage. Turn it on, pay a bit more, done.