Transitive Replication in RavenDB
Join the DZone community and get the full member experience.
Join For Freetldr;
replication topologies make my head hurt.
one of our customers had an interesting requirement, several months ago:
basically, he wanted to write a document at node #1, and have it replicate, through node #2, to node #3. that was an easy enough change, and we did that. but then we got another issue from a different customer, who had the following topology:
and that client problem is that when making a write to node #1, it would be replicated to nodes 2 – 4, each of which would then try to update the other two with the new replication information (it would skip node #1 because it is the source). that would cause… issues, because they already had that document in place.
in order to resolve that, i added a configuration option, which controls whatever the node that we replicate to should receive only documents that were modified on the current node, or whatever we need to include documents that were replicated to us from other nodes as well.
it is a relatively small change, code wise. of course, documenting this, and all of the options that follows is going to be a much bigger task, because now you have to make a distinction between replicating nodes, gateway nodes, etc.
Published at DZone with permission of Oren Eini, DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.
Trending
-
13 Impressive Ways To Improve the Developer’s Experience by Using AI
-
The Role of AI and Programming in the Gaming Industry: A Look Beyond the Tables
-
How To Scan and Validate Image Uploads in Java
-
Exploring the Capabilities of eBPF
Comments