Hi, Jose, Thanks for the reply.
The following are the steps of AddVoter. The bulk of the time is probably in step 5, but the updated VotersRecord won't be written until step 6. So, ideally, the controller leader should report the pending voter as soon as step 1. The brokers and non-leader controllers can't do that until after step 6. Having multiple brokers report the same metric can be confusing when there is inconsistency. 1. Wait until there are no uncommitted VotersRecord. Note that the implementation may just return a REQUEST_TIMED_OUT error if there are pending operations. 2. Wait for the LeaderChangeMessage control record from the current epoch to get committed. Note that the implementation may just return a REQUEST_TIMED_OUT error if there are pending operations. 3. Send an ApiVersions RPC to the first listener to discover the supported kraft.version of the new voter. 4. Check that the new voter supports the current kraft.version. 5. Wait for the fetch offset of the replica (ID, UUID) to catch up to the log end offset of the leader. 6. Append the updated VotersRecord to the log. 7. The KRaft internal listener will read this record from the log and add the voter to the voters set. 8. Wait for the VotersRecord to commit using the majority of new voters set. Return a REQUEST_TIMED_OUT error if it doesn't succeed in time. 9. Send the AddVoter response to the client. Jun On Wed, Mar 27, 2024 at 7:52 PM José Armando García Sancio <jsan...@confluent.io.invalid> wrote: > Hi Jun, > > On Wed, Mar 27, 2024 at 2:26 PM Jun Rao <j...@confluent.io.invalid> wrote: > > 55.1 How does the broker and non-leader controller know the pending > voters? > > They are in the log. Pending voter sets are VotersRecords between the > HWM and the LEO. The leader will make sure that there is at most one > VoterRecord that is uncommitted (between the HWM and LEO). > > Maybe uncommitted-voter-change is a better name. Updated the KIP to > use this name. > > Thanks, > -- > -José >
