lh0156 commented on code in PR #22937:
URL: https://github.com/apache/kafka/pull/22937#discussion_r3703828409
##########
clients/src/main/java/org/apache/kafka/common/config/TopicConfig.java:
##########
@@ -199,7 +199,13 @@ public class TopicConfig {
public static final String UNCLEAN_LEADER_ELECTION_ENABLE_CONFIG =
"unclean.leader.election.enable";
public static final String UNCLEAN_LEADER_ELECTION_ENABLE_DOC = "Indicates
whether to enable replicas " +
"not in the ISR set to be elected as leader as a last resort, even
though doing so may result in data " +
- "loss.<p>Note: In KRaft mode, when enabling this config dynamically,
it needs to wait for the unclean leader election" +
+ "loss. Enabling this configuration for a topic that uses transactions
is incompatible with exactly-once " +
+ "semantics. An unclean election can remove a transaction's COMMIT or
ABORT marker from the elected replica, " +
+ "causing consumers with <code>isolation.level=read_committed</code> to
stop at the last stable offset. " +
+ "If this occurs, use <code>kafka-transactions.sh find-hanging</code>
to identify the affected transaction and " +
+ "<code>kafka-transactions.sh abort</code> to recover it. Verify the
transaction and partition before aborting " +
+ "it, since an unclean election may already have caused data loss." +
+ "<p>Note: In KRaft mode, when enabling this config dynamically, it
needs to wait for the unclean leader election " +
Review Comment:
Agreed. I added
`UncleanLeaderElectionTest.testUncleanLeaderElectionCanLeaveReadCommittedConsumerAtLastStableOffset`
in commit `6dab67ed22`. The test reproduces the missing transaction-marker
scenario with a transactional producer, stops the follower before the marker is
replicated, performs an unclean election, and verifies that a `read_committed`
consumer stops at the last stable offset. It passes for both Raft-Isolated and
Raft-Combined with `./gradlew :server:test --tests
org.apache.kafka.server.UncleanLeaderElectionTest.testUncleanLeaderElectionCanLeaveReadCommittedConsumerAtLastStableOffset
--no-build-cache --console=plain`.
The documentation now scopes `kafka-transactions.sh find-hanging` and
`abort` to the case where producer state is still available, explicitly warns
that they cannot restore a lost marker or data, and asks operators to verify
the transaction and partition before aborting. I did not imply that these
commands repair the unclean-election data loss.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
