Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

Dynamic Node Distribution in RavenDB 4.0

DZone's Guide to

Dynamic Node Distribution in RavenDB 4.0

Get an in-depth, visual explanation of dynamic node distribution in RavenDB and how nodes can qualify to be full members in a database.

· Database Zone ·
Free Resource

RavenDB vs MongoDB: Which is Better? This White Paper compares the two leading NoSQL Document Databases on 9 features to find out which is the best solution for your next project.  

This is another cool feature that is best explained by showing rather than by just explaining.

Consider the following cluster, made of three nodes.

On this cluster, we created the following database:

This data is hosted on Node B and Node C, so we have a replication factor of 2. Here is how the database topology looks:

And now we are going to kill Node B.

The first thing that is going to happen is that the cluster will mark this node as suspect. In this case, the M on Node C stands for Member, and the R on Node B stands for Rehab.

Shortly afterward, we'll detect that it is actually down:

And this leads to a problem. We were told that we need to have a replication factor of 2 for this database, but one of them is down. There is a grace period, of course, but the cluster will eventually decide that it needs to be proactive about it and not wait around for nodes long past, hoping they'll call, maybe.

So the cluster is going to take steps to do something about it:

And it does! It added Node A to the database group. Node A is added as a promotable member, and Node C is now responsible for catching it up with all the data that is in the database.

Once that is done, we can promote Node A to be a full member in the database. We'll remove Node B from the database entirely, and when it comes back up, we'll delete the data from that node.

On the other hand, if Node B was able to get back on its feet, it would be a race between Node A and Node B to see who would be the first node to become eligible to be a full member in the cluster again.

In most cases, that would be the pre-existing node since it has a head start on the new node.

Clients, by the way, are not really aware that any of this is happening; the cluster will manage the topology and let them know which nodes they need to talk to at any given point.

Oh, and just to let you know, these images are screenshots from the studio; you can actually see this happening live when we introduce failure into the system and watch how the cluster recovers from it.

Aggregations provide vital intelligence to the success of a business. Crush the challenge of providing real time aggregations for daily, weekly, and monthly totals without having to tie up your servers.

Topics:
database ,ravendb ,node distribution ,dynamic nodes ,cluster

Published at DZone with permission of

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}