Hello!I'm new to Raft.I'm trying to figure out whether it is suitable for my application, before I dive deeper.I'm working on an embedded application with 4 "servers" which may or may not be on, and may or may not communicate with each other. Whichever servers are on and visible have to agree to a "state".Is it possible, in case [less than] half of the servers are on, to choose a leader and agree to a state?Maybe an initial cluster of 2 can be defined, and change the cluster configuration when more servers are available?
Any suggestions are welcome!Thank you to all in advance!Ex
--
You received this message because you are subscribed to the Google Groups "raft-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to raft-dev+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/raft-dev/6ac31795-28b8-4cbf-afd1-07ce36c7bf20n%40googlegroups.com.
Choosing a small cluster size and then growing is possible. You should avoid an even number of nodes for your clusters.
Taking your bolded question more broadly, this situation, to the involved servers, is indistinguishable from the situation where there is a networking or other error to partition the cluster, and both minority groups carry on the cluster separately, leading to two completely different versions of history.
Raft is made for live clusters where all nodes can communicate with each other reasonably quickly. Some of the fundamental properties depend on this. To handle a situation where normal operation means being off the network or not being in guaranteed contact with everyone else, I think you are better off looking for a sync/CDRT solution.
As an example, RavenDB is a database product using Raft for its clusters, but is also in use in your type of scenario, and it is my understanding that it has to use different technology to make this happen.
Regards,
/Jesper
--
Choosing a small cluster size and then growing is possible. You should avoid an even number of nodes for your clusters.
Sorry, I misspelled ”CRDT”.
/Jesper
To view this discussion on the web visit https://groups.google.com/d/msgid/raft-dev/f05805cac4ad4fa3a4408e50b6d239b2%40Exchange2013.treetop.local.
To rephrase what I said before to make the point better:
Raft (and other cluster consensus algorithms) is great if you have a cluster of nodes that always can communicate with each other and need to proceed in lockstep, but where for availability and robustness you want to gracefully handle nodes failing.
However, if one node can be off doing its own thing, maybe needs to work offline and sporadically gets to see the other nodes and synchronize what it has been doing, this requires an entirely different set of solutions. If half of the nodes can be unreachable at any given time, that’s not a workable cluster. It doesn’t mean you can’t solve your problem, it just means you’ll have to pick another way of solving it. CRDTs and offline sync algorithms are built for this and Raft isn’t.
To view this discussion on the web visit https://groups.google.com/d/msgid/raft-dev/c71b389a-563d-4a7a-bd2d-a2050e86d837n%40googlegroups.com.