Page History

...

Once the RemoveVoterRecord operation has been committed by the majority of the new voter set, the leader can respond to the RPC and . If the removed voters is the leader, the leader will resign from the quorum if the removed replica is the leaderwhen the RemoveVoterRecord has been committed. To allow this operation to commit the followers will continue to fetch from the leader even if the leader is not part of the new voter set.

...

The section describe how the quorum will get bootstrap to support this KIP. There are two configurations that Kafka will support and each will be explain separately. The Kafka cluster can be configured to used use the existing controller.quorum.voters  or the new property called controller.quorum.bootstrap.servers.

...

This is a static quorum configuration where all of the voters' ID, host and port are specified. An example value of for this configuration is 1@localhost:9092,2@localhost:9093,3@localhost:9094 .

When this option is used the leader of the KRaft topic partition will not allow the AddVoter RPC RPCs to add replica IDs that are not describe in the configuration and it would not allow the RemoveVoter RPC RPCs to completely remove replica IDs that are described in the configuration. This means that the replica UUID can change by using sequence of AddVoter and RemoveVoter but the client cannot add new replica id or remove replica id from the set of voters.

...

When using this configuration the quorum will be started with only one voter. This voter is bootstrapped by running the kafka-storage.sh tool. This tool will create the cluster metadata partition and append one AddVoterRecord to it. Additional voters can get added by using the AddVoter RPC as describe described in this KIP.

Leader Election

...