Consistency of Raft while leader fails

[Mujahid Masood]

Hello,

Raft Leader does consistency checks for logs to be in sync with followers.

Let's assume a scenario when Leader was doing consistency checks and leader failed for some time t, is it possible that it will cause logs to be in inconsistent state?

or leader failure can not impact consistency of logs?

[Jordan Halterman]

The question is if a leader fails, is it possible for the logs to be in an inconsistent state? Sure it is, but the inconsistent entries will never be committed. Raft guarantees that entries that are *committed* are the same on all nodes, and consistency checks are really only done on uncommitted entries.

But actually, the leader sends information to followers and followers perform consistency checks to determine whether their logs are consistent with the leader's. The leader election protocol guarantees that whatever leader is elected will have all committed entries, and the leader's log is then replicated to followers.

--
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+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Mike Percy]

I'll take a stab at interpreting this question in a slightly different way.

Maybe you are worried about things changing without the leader's supervision or that uncommitted changes could become visible.

In Raft, only the leader can write to the log and replicate to followers, and systems that implement Raft are generally serving reads from the state machine that the log is replicating committed changes to, so uncommitted stuff in the log shouldn't ever be visible to users.

If you want to consider reading state from arbitrary followers, then yes you can see a delayed version of the state machine if you hit a slow follower. If you need strict consistency of state machine reads, solutions to that typically involve always reading from the current leader, and ensuring the node you think is the leader really is the latest leader by using leader leases or other approaches discussed in Diego Ongaro's dissertation.

Mike

[Arthur Wang]

To avoid reading from stale data , besides reading directly from the leader , is it also possible that the follower broadcast the read request through all the nodes , then select the lastest marjority confirmed version of data as the one needed and  return it to client ?  That is :

1>  Client send the read requests randomly to the nodes, whether it's a leader or a follower.

2>  Each follower has a seperate RPC interface named like 'InnterRead' specifically for this purpose.  It returns the lastest version of data from its replicated log ,not the committed state machine.

3>  If a follower receive a read request from client ,broadcasting it among the cluster, pick up the lastest majority confirmed version of data , return it to the client. Since it is majority confirmed and lastest, it must be the same with the version in leader's state machine.

This can help leader to reduce a great amount of reading payload , but also introduce great traffics(increasing linearly as #nodes grows)  inside the cluster.  I think this is a tradeoff suitable for a fifty-fifty read-write application.

Are there implementations done like this ?

--
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.

[Oren Eini (Ayende Rahien)]

It would be easier (and safer) to just forward the request to the leader. Otherwise, you get into a fully connected mesh, and that is probably something that you don't want to do.

To unsubscribe from this group and stop receiving emails from it, send an email to raft-dev+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

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+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

Oren Eini CEO   /   Hibernating Rhinos LTD Mobile:  +972-52-548-6969 Sales:  sa...@ravendb.net Skype:  ayenderahien Support:  sup...@ravendb.net