Okay, thank you very much. This is the process of ratis member change that I have learned: Before the new server S successfully joins the group, S will first accept snapshots and log entries from leader, and then leader start the raft member change process. For example, leader append (old, new) conf log entry. After (old, new) is committed, replicate (new) conf log entry until (new) conf log entry is committed. At this time, it can return Client success. Do you understand it correctly? At this time, the client success can be returned. Is the understanding correct?
Tsz Wo Sze <[email protected]> 于2024年8月16日周五 23:39写道： > > Can the client ensure that the lifeCycle of the new empty server D is > > RUNNING when it receives a response that the member change is completed? > > Yes, server D will be in RUNNING state when the client gets a SUCCESS > reply. A SUCCESS reply means that the setConf is completed successfully, > which means that the new server D is bootstrapped successfully. > > Tsz-Wo > > > On Fri, Aug 16, 2024 at 8:34 AM Tsz Wo Sze <[email protected]> wrote: > > > > ... S needs to fully receive the snapshot and log entries > > > sent by the leader before S can start a FollowerState, right? If there > > are > > > many snapshots and log entries, will the STARNING state of S last for a > > > long time? > > > > That's correct. It only needs to get the latest snapshots and the latest > > log entries. When the servers are configured correctly, the Leader will > > take a snapshot from time to time and purge the old log entries. The > size > > of the latest snapshots and the latest log entries is about the size of > > the state of the server. > > > > Of course, the time depends on the size of the state and network speed. > > In a modern network, sending gigabytes of state should not be a problem. > > > > Tsz-Wo > > > > > > > > On Thu, Aug 15, 2024 at 9:09 PM ka yuu <[email protected]> wrote: > > > >> Um, sorry, please allow me to ask another question. When a client > >> initiates > >> a member change request, for example, from (A, B, C) - > (A, B, C, D). > >> Can the client ensure that the lifeCycle of the new empty server D is > >> RUNNING when it receives a response that the member change is completed? > >> If it cannot be ensured that D is already in RUNNING when returned, the > >> leader crash in this group , and this RaftGroup will not work > >> Yuuka > >> > >> ka yuu <[email protected]> 于2024年8月16日周五 10:05写道： > >> > >> > Oh, thank you. I roughly understand that if the new empty server S is > >> not > >> > in the startup conf, S needs to fully receive the snapshot and log > >> entries > >> > sent by the leader before S can start a FollowerState, right? If there > >> are > >> > many snapshots and log entries, will the STARNING state of S last for > a > >> > long time? > >> > > >> > Tsz Wo Sze <[email protected]> 于2024年8月16日周五 00:34写道： > >> > > >> >> > ... why proto is not initilizing is needed. ... > >> >> > >> >> It is for bootstrapping a new, empty server S and letting it join an > >> >> existing cluster. > >> >> > >> >> S: When it starts, it transits NEW -> STARTING > >> >> S: It checks if it is in the startup conf. If yes, transits STARTING > >> -> > >> >> RUNNING and starts a FollowerState. If no, remains in STARTING. > >> >> > >> >> The leader bootstraps S by sending a snapshot, if there is any, and > log > >> >> entries. When the bootstrap process is ongoing, it > >> >> sets AppendEntriesRequestProto.initializing to true. Then, the > server > >> S > >> >> remains in STARTING and won't start a FollowerState since it is not > >> ready. > >> >> > >> >> Tsz-Wo > >> >> > >> > > >> > > >
