Groups keyboard shortcuts have been updated
Dismiss
See shortcuts

Is lost Update possible with Raft ?

50 views
Skip to first unread message

Tarun Pahuja

unread,
Dec 25, 2024, 11:56:12 PM12/25/24
to raft-dev
Hi,

Can you please help me know if such a scenario is possible with RAFT ?.

Lets say we have a cluster of 5 nodes A-E with A as a Leader and following sequence of events take place:

1. A sends the replicate change request parallely to all the followers. 
2. Only B could receive the request as C-E crashed or partitioned just before receiving the change. 
3. Leader A tries multiple times to get majority and finally crashed. 
4. C - E comes online again. B - E waits for election timeout to restart the election
5. C becomes the candidate and win the election as it creates a majority with C - E 
6. Uncommitted Write is lost. 

Such a case is possible even if the leader ensure with pre-voting.

Regards,
Tarun

A. Jesse Jiryu Davis

unread,
Dec 26, 2024, 8:17:53 AM12/26/24
to raft...@googlegroups.com
Yes, Tarun, uncommitted writes can be lost. That's basically the definition of "uncommitted"! The scenario you describe is one way to lose uncommitted writes, there are other ways as well. Raft guarantees that a committed write is not lost if a majority of nodes survives. 

--
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 visit https://groups.google.com/d/msgid/raft-dev/8273df2e-9fd8-4695-bfa8-a44cd3cf1021n%40googlegroups.com.

Tarun Pahuja

unread,
Dec 26, 2024, 11:07:36 AM12/26/24
to raft-dev
Thanks,

Given that uncommitted write may or may not survive, How should the application replying on RAFT protocol behaves in such a case.

A. Jesse Jiryu Davis

unread,
Dec 26, 2024, 9:53:15 PM12/26/24
to raft...@googlegroups.com
Something like this (see "In Search of an Understandable Consensus Algorithm" §8 for details):
  • The application, via a Raft client, sends a command to the Raft leader, along with a unique serial number.
  • The Raft leader tries to commit the command.
  • If the leader successfully commits the command, it replies to the application, via the client. The application now knows the command is durable.
  • If the leader crashes without replying, the application doesn't know if the next leader will commit the command or not. The client should wait until a new leader is elected and auto-retry the command, with the same serial number. The new leader can detect if it already has this command in its log. If not, it adds the command to its log. Either way, the leader waits for the command to be committed, then replies to the client.
This logic is implemented in LogCabin, MongoDB, and some other Raft-like systems. It requires logic on the client and server.

Reply all
Reply to author
Forward
0 new messages