Ayende @ Rahien

Hi!
My name is Oren Eini
Founder of Hibernating Rhinos LTD and RavenDB.
You can reach me by phone or email:

ayende@ayende.com

+972 52-548-6969

, @ Q c

Posts: 18 | Comments: 72

filter by tags archive

RavenDB Clusters & Write Assurances

time to read 3 min | 563 words

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:

   1: await session.StoreAsync(user);
   2: await session.SaveChangesAsyng(); // save to one of the nodes
   3:  
   4: var userEtag = session.Advanced.GetEtagFor(user);
   5:  
   6: 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.


Comments

Mircea Chirea

Would it be possible to have this inside a transaction, so it either saves and replicates to, say, 2 total nodes, or none?

Otherwise you save to one, but it may fail during the replication wait. What do you do then? The doc might have been saved, it's just that the node went down, so you'll see it later.

But what if I need to make sure it's saved on X nodes, or it isn't saved at all?

Ayende Rahien

Mircea, No, that is not possible. If this is something that you need, you would need to write to the N nodes you want yourself in a DTC transaction. Note that we support this, but don't recommend its usage. It is very expensive.

Mauro Destro

If I'm reading tha same user from another master I can't be sure it's the current one right? Or it's a obvious condition and so a fallacy of my architecture?

Ayende Rahien

Mauro, That depend on your actual topology. By default, replication is for HA. If you care for seeing the latest, you read from the master. If you don't care, you read from any node.

Troy

Will this only work with the Async methods? IE: StoreAsync, SaveChangesAsync.

Ayende Rahien

Troy, Nope, you can call it from sync session as well. You would just need to call WaitAsync().Wait() to force it to physically wait.

Comment preview

Comments have been closed on this topic.

FUTURE POSTS

  1. RavenDB 3.0 New Stable Release - 5 hours from now
  2. Production postmortem: The industry at large - about one day from now
  3. The insidious cost of allocations - 2 days from now
  4. Buffer allocation strategies: A possible solution - 5 days from now
  5. Buffer allocation strategies: Explaining the solution - 6 days from now

And 3 more posts are pending...

There are posts all the way to Sep 11, 2015

RECENT SERIES

  1. Find the bug (5):
    20 Apr 2011 - Why do I get a Null Reference Exception?
  2. Production postmortem (10):
    01 Sep 2015 - The case of the lying configuration file
  3. What is new in RavenDB 3.5 (7):
    12 Aug 2015 - Monitoring support
  4. Career planning (6):
    24 Jul 2015 - The immortal choices aren't
View all series

RECENT COMMENTS

Syndication

Main feed Feed Stats
Comments feed   Comments Feed Stats