--
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/CAEajhJM54tX2YQ%2BKKZVM1EAQqQSEEhnFgY1S0afemKGfpo120Q%40mail.gmail.com.
Hi Philip,To avoid stale reads, you must replicate the read request as any other request (ensuring the majority of the nodes confirm). This approach ensures that you get the most recent data (not only the leader's view of the data).
I don’t think you’re missing anything. You’re absolutely right that the heartbeat needs to happen after reading the state for reads to be linearizable. But that’s what the paper is saying. It says to exchange heartbeats with a majority of the cluster before *responding* to read-only requests, and that means after reading the leader’s state machine but before sending the response to the client.
However, I'm still not 100% convinced. :-) Couldn't this happen?
- Leader receives read request
- Leader reads state machine
- Leader exchanges heartbeats with majority of nodes successfully
- Leader responds to the client with the data it read in step #2.
--
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/87wmiiel7r.fsf%40carbon.mail-host-address-is-not-set.
To view this discussion on the web visit https://groups.google.com/d/msgid/raft-dev/ad58ead0-7ccd-4c69-b66c-bcbd0fbdb8a9n%40googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/raft-dev/CABUcDvN%2BWZZoMMQhQoDPL_jYNLY6TUsmJ_Fbd0pdw_6JiAxBgQ%40mail.gmail.com.
Hi all,I'm a bit late to chime in here. I agree with what Archie and Free wrote above. I just wanted to add that some more detailed steps for processing read-only requests while preserving linearizability are in my dissertation ( https://github.com/ongardie/dissertation ), section 6.4 "Processing read-only queries more efficiently". I'll highlight two things from there:
1. The leader's commit index isn't necessarily up-to-date until it has committed one of its own entries, so it's critical to wait for that to happen. You might want to review your code to make sure.
Free -- I just want to confirm one last time, now Diego chimed in. You seem to believe that there is an implicit statement in the Section 6.4 Processing read-only queries more efficiently that the Heartbeats are done within the same Raft term as the storing of the Commit Index in readIndex (to use the variable name from the dissertation) was done.This makes sense to me, because otherwise I seem to be able to come up with a scenario whereby the value of readIndex is set, but the node isn't actually "really" the Leader (it just thinks it is, but it's been partitioned, and there is actually another Leader on the cluster at the time),
You've linked to where hashicorp/raft appends a no-op entry when a server becomes leader. The leader's commit index is not up-to-date until that entry has been committed. Is there anything preventing rqlite from reading the commit index before that no-op entry has committed?
CommitIndex returns the committed index. This API maybe helpful for server to implement the read index optimization as described in the Raft paper.
Nothing about ensuring that the initial log has actually been committed before calling this. I'll need to dig into this, there may be something else in the library that helps, I'm so close to getting this code right.
Philip