5 ms·

Can't this lose commits? It looks like the message to commit the log entry to the followers happens after the message to the client to say that the commit is c

Can't this lose commits? It looks like the message to commit the log entry to the followers happens after the message to the client to say that the commit is confirmed. The client can't actually tell when their commit has been replicated. If the leader dies before sending that confirm to the followers, the client will end up thinking the new leader has a commit which it's going to have to roll back. Is this something the full algorithm handles differently to the way the diagrams would indicate?

skew 12y ago
The response to the client is only sent after a majority of followers have the log entry. That's described in the text in the "Protocol Overview", and nicely animated in "Log Replication".
- regularfry 12y ago
  Yes, they have the log entry, but it can still be rolled back, can't it? Here's how I understand the process: 1. Client sends log entry to leader 2. Leader appends log entry, forwards it to followers 3. Majority of followers confirm 4. Leader commits the log entry 5. Leader confirms the commit to the client 6. Followers commit on the next heartbeat What happens if the leader goes away between 5 and 6? To my eyes, it looks like the followers will time out, elect a new leader, and have to roll back the last log entry.
  - DanWaterworth 12y ago
    If an entry has been replicated to a majority of followers, then the new leader is guaranteed to have that entry and therefore it won't be rolled back.
    - regularfry 12y ago
      How does the new leader know it went to a majority? The only entity which could confirm that is the old leader.
      - Muzzaf 12y ago
        That is correct. The solution to this is given in section 5.4.1 (election restriction), section 5.4.2 (Committing entries from previous terms) and section 8 (Client interaction) of the Raft paper. Roughly, a newly elected leader will have all committed entries (guaranteed by the "election restriction", 5.4.2) but it does not know precisely which are committed. The new leader will commit a no-op log entry (section 8) and after it has received replies from a majority of the cluster it will know which entries have already been committed.
        regularfry 12y ago
        Ooh, thanks. The no-op commit is particularly interesting.
Too 12y ago
This is the whole idea of a distributed storage. You add many nodes (that are only confirmed to have the transaction in memory) to reduce the probability of all nodes crashing during one commit and this is considered more reliable than locking the whole data storage to wait for a confirmed disc write. I'm assuming you mean commit==write to disc? ie. P(client queuing up too many requests and crashing because db is too slow waiting for disc) > P(5 distributed db nodes with the transaction in memory crashing simultaneously before it was written to disc)
- regularfry 12y ago
  I'm assuming "commit" means whatever "commit" means in the linked document. EDIT: and it's not P(5...), it's P(Leader...) in the case I'm worrying about.
erikb 12y ago
Either one or both sides of a split can't gain majority. Therefore you won't get a success message until you can be sure that the data won't get overwritten after a split is reconnected.

skew 12y ago

The response to the client is only sent after a majority of followers have the log entry. That's described in the text in the "Protocol Overview", and nicely animated in "Log Replication".

regularfry 12y ago
Yes, they have the log entry, but it can still be rolled back, can't it? Here's how I understand the process: 1. Client sends log entry to leader 2. Leader appends log entry, forwards it to followers 3. Majority of followers confirm 4. Leader commits the log entry 5. Leader confirms the commit to the client 6. Followers commit on the next heartbeat What happens if the leader goes away between 5 and 6? To my eyes, it looks like the followers will time out, elect a new leader, and have to roll back the last log entry.
- DanWaterworth 12y ago
  If an entry has been replicated to a majority of followers, then the new leader is guaranteed to have that entry and therefore it won't be rolled back.
  - regularfry 12y ago
    How does the new leader know it went to a majority? The only entity which could confirm that is the old leader.
    - Muzzaf 12y ago
      That is correct. The solution to this is given in section 5.4.1 (election restriction), section 5.4.2 (Committing entries from previous terms) and section 8 (Client interaction) of the Raft paper. Roughly, a newly elected leader will have all committed entries (guaranteed by the "election restriction", 5.4.2) but it does not know precisely which are committed. The new leader will commit a no-op log entry (section 8) and after it has received replies from a majority of the cluster it will know which entries have already been committed.
      - regularfry 12y ago
        Ooh, thanks. The no-op commit is particularly interesting.

Too 12y ago

This is the whole idea of a distributed storage. You add many nodes (that are only confirmed to have the transaction in memory) to reduce the probability of all nodes crashing during one commit and this is considered more reliable than locking the whole data storage to wait for a confirmed disc write. I'm assuming you mean commit==write to disc? ie. P(client queuing up too many requests and crashing because db is too slow waiting for disc) > P(5 distributed db nodes with the transaction in memory crashing simultaneously before it was written to disc)

regularfry 12y ago
I'm assuming "commit" means whatever "commit" means in the linked document. EDIT: and it's not P(5...), it's P(Leader...) in the case I'm worrying about.

erikb 12y ago

Either one or both sides of a split can't gain majority. Therefore you won't get a success message until you can be sure that the data won't get overwritten after a split is reconnected.