Yes, that is correct. Tsz-Wo
On Fri, Aug 16, 2024 at 9:02 AM ka yuu <[email protected]> wrote: > 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 > > >> >> > > >> > > > >> > > > > > >
