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 >> >
