Seeking help to get the clarity on a commit phase

[Kalpa 1977]

Hi all,

      Thought to check about a case in Distributed Consensus.

for example.

1. Leader gets the command.

2. send to followers and followers update the command.

3. leader commit the command after getting the ack from enough nodes

4. in this case, if the leader crashes, how the future leaders knows that this log has been committed? 

1) other nodes not committed the data, only leader node committed.

2) some nodes commits and some other does not commit. unfortunately, committed nodes does not participate in the election.

Thanks,

Kalpa 

[Oren Eini (Ayende Rahien)]

They do not know that.

What is guaranteed that if the command is on the majority, the leader would have that command. 

Then the first action that the leader does is commit an entry from its own term, which will commit all previous commands.

--
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/fb6ac81f-794f-4428-b9ee-f50ada1105bcn%40googlegroups.com.

--

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

[Kalpa 1977]

Hi Oren Eini, 

     thanks for the response,So, how the system is reliable here for the current commit. if the leaders crashes after sending ack to the client, from the client perspective, 

or does it wait for the commit at the follower and send the ack to the client?

thanks,

Kalpa

On Wed, Dec 15, 2021 at 11:55 AM 'Oren Eini (Ayende Rahien)' via raft-dev <raft...@googlegroups.com> wrote:

They do not know that.

What is guaranteed that if the command is on the majority, the leader would have that command. 

     Then the first action that the leader does is commit an entry from its own term, which will commit all previous commands.

thanks again for the quick help.

Kalpa 

You received this message because you are subscribed to a topic in the Google Groups "raft-dev" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/raft-dev/yoaj8BCBtiA/unsubscribe.
To unsubscribe from this group and all its topics, 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/CAF0G-ZiF1Y4%2BtLFe%2Bad3Rt_6h5M6%2BcbxkVSYKdA9tH%2BqmOHe4g%40mail.gmail.com.

[Unmesh Joshi]

The client interactions need to be handled to make sure there are no duplicates when client retries. The Raft thesis describes a mechanism to assign unique numbers to each request and, if a client retries the same request, the request will be ignored by the state machine. This is true for any client-server interactions, not just for Raft. e.g. Kafka implements idempotent producers in a similar way. So I have tried to document it as a patterns https://martinfowler.com/articles/patterns-of-distributed-systems/idempotent-receiver.html

To view this discussion on the web visit https://groups.google.com/d/msgid/raft-dev/CAEkvJf1_3y08-QNwWQoqdq2QpuoYvbGALHoOb_2NAi1UDhp2Fg%40mail.gmail.com.

[Soham Dongargaonkar]

The answer to your question is: it doesn't matter.

1. If the leader committed that entry, then it means a majority of the nodes have that entry.

2. This means in an election, only nodes that have that entry will be able to become the next leader.

3. Once they become the new leader, they will eventually see that that entry is replicated. Then, they will commit that entry to their own state machine and tell the other nodes to increase their commit indices.

[Chao Tan]

Hi kalpa:

   This question is common for raft beginner. If you have ever read raft paper, you will know in raft election, node does not care about which log has every been committed. 

The node is only care about the logs' length and version.  Raft algorithm guarantees that the most logs owner will have all the logs which had ever achieved to consensus state.

For this point, you can refer to safety proof in raft paper.

Thanks,

linfeng

--
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/fb6ac81f-794f-4428-b9ee-f50ada1105bcn%40googlegroups.com.

--

Tan Chao

 

Embedded and Pervasive Computing Center

Department of Computer Science and Engineering

Shanghai Jiao Tong University

 

Address: SEIEE East-309, Dongchuan Road 800, Minhang, Shanghai, China 200240

Email: 1991...@gmail.com

[Unmesh Joshi]

I have tried to document it in a slightly more generic way here 

https://martinfowler.com/articles/patterns-of-distributed-systems/replicated-log.html

To view this discussion on the web visit https://groups.google.com/d/msgid/raft-dev/CAPbkkAqGsjeFWOGDOyBsxbCmavwKwhZSVVhvkdsjnXzeLrM%2BNg%40mail.gmail.com.