[
https://issues.apache.org/jira/browse/KAFKA-17030?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
José Armando García Sancio updated KAFKA-17030:
-----------------------------------------------
Description:
This issues depends on implementing
https://issues.apache.org/jira/browse/KAFKA-16164
Because of reconfiguration it is possible for a local replica to think that
they are a voter but the KRaft leader doesn't have them in the voter set. Think
a voter removal that committed before it was replicated to the removed voter.
To address this issue KIP-853 suggest using Pre-Vote to fence the local replica
from increasing their epoch. But in this state the local replica will be stuck
because it will never discover the new leader. To fix this, voters must send
Fetch requests to the bootstrap server and or the known leader while in the
prospective state. This is similar to how observer discover the leader in the
unattached and follower state.
was:
This issues depends on implementing
https://issues.apache.org/jira/browse/KAFKA-16164
Because of reconfiguration it is possible for a local replica to think that
they are a voter but the KRaft leader doesn't have them in the voter set. Think
a voter removal that committed before it was replicated to the removed voter.
To address this issue KIP-853 suggest using Pre-Vote to fence the local replica
from increasing their epoch. But in this state the local replica will be stuck
because it will never discover the new leader. To fix this voters must send
Fetch requests to the bootstrap server and or the known leader while in the
prospective state. This is similar to how observer discover the leader in the
unattached and follower state.
> Voters should not assume that the leader will send them BeginQuorumEpoch
> requests
> ---------------------------------------------------------------------------------
>
> Key: KAFKA-17030
> URL: https://issues.apache.org/jira/browse/KAFKA-17030
> Project: Kafka
> Issue Type: Sub-task
> Reporter: José Armando García Sancio
> Assignee: Alyssa Huang
> Priority: Major
>
> This issues depends on implementing
> https://issues.apache.org/jira/browse/KAFKA-16164
> Because of reconfiguration it is possible for a local replica to think that
> they are a voter but the KRaft leader doesn't have them in the voter set.
> Think a voter removal that committed before it was replicated to the removed
> voter.
> To address this issue KIP-853 suggest using Pre-Vote to fence the local
> replica from increasing their epoch. But in this state the local replica will
> be stuck because it will never discover the new leader. To fix this, voters
> must send Fetch requests to the bootstrap server and or the known leader
> while in the prospective state. This is similar to how observer discover the
> leader in the unattached and follower state.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
