RavenDB Clusters and Write Assurances
Join the DZone community and get the full member experience.Join For Free
RavenDB handles replication in an async manner. Let us say that you have 5 nodes in your cluster, set to use master/master replication.
That means that you call SaveChanges(), the value is saved to the a node, and then replicated to other nodes. But what happens when you have safety requirements? What happens if a node goes down after the call to SaveChanges() was completed, but before it replicate the information out?
In other systems, you have the ability to specify W factor, to how many nodes this value will be written before it is considered “safe”. In RavenDB, we decided to go in a similar route. Here is the code:
await session.StoreAsync(user); await session.SaveChangesAsyng(); // save to one of the nodes var userEtag = session.Advanced.GetEtagFor(user); var replicas = await store.Replication.WaitAsync(etag: userEtag, repliacs: 1);
As you can see, we now have a way to actually wait until replication is completed. We will ping all of the replicas, waiting to see that replication has matched or exceeded the etag that we just wrote. You can specify the number of replicas that are required for this to complete.
Practically speaking, you can specify a timeout, and if the nodes aren’t reachable, you will get an error about that.
This gives you the ability to handle write assurances very easily. And you can choose how to handle this, on a case by case basis (you care to wait for users to be created, but not for new comments, for example) or globally.
Published at DZone with permission of Oren Eini, DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.