Replies: 2 comments 1 reply
-
Two node clusters are an explicitly unsupported configuration: there is no such thing as a majority when one node fails. |
Beta Was this translation helpful? Give feedback.
0 replies
-
This is expected behaviour. The leader doesn't care if the follower was able to process the command it only cares about if the command was added to the follower's log successfully, which it was (if it wasn't in this case the follower would never have tried to apply it). Please ensure your state machine logic is deterministic and does not rely on environment specific data points. |
Beta Was this translation helpful? Give feedback.
1 reply
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
Describe the bug
If a ra_machine crashes while processing a command, the command is committed on the raft log even if no majority is reached on the cluster.
Note:
I know that ra machines must be written not to crash #294 (comment), but in this case I expect the command not to be committed.
Reproduction steps
iex --name [email protected] -S mix
iex --name [email protected] -S mix
ra_server on node2 restarts and then the supervisor terminates it (as expected)
but on node1 process_command returns
{:ok, "COMMAND", {:quick_start, :"[email protected]"}}
.Expected behavior
Since the issued command is not acknowledged by node2 the cluster has no agreed on the log entry.
Therefore the command should not be committed.
Additional context
No response
Beta Was this translation helpful? Give feedback.
All reactions