k/group: recover leader epoch on leader change #17260
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
new failures in https://buildkite.com/redpanda/redpanda/builds/46616#018e668c-9526-49f5-97e6-de141da9ca44: |
|
ducktape was retried in https://buildkite.com/redpanda/redpanda/builds/46616#018e669e-a59b-4cd6-9f6d-56626702fc2e ducktape was retried in https://buildkite.com/redpanda/redpanda/builds/46640#018e681b-7814-4b5c-a686-1dcbb45692dc ducktape was retried in https://buildkite.com/redpanda/redpanda/builds/46640#018e681f-84c3-4a5d-a9b7-ed837d00e5be ducktape was retried in https://buildkite.com/redpanda/redpanda/builds/46718#018e7701-2d62-4e94-8fe3-c807d2de1e0e |
|
/dt |
|
failing test with verifiable consumer; without write caching... https://ci-artifacts.dev.vectorized.cloud/redpanda/46616/018e668c-9526-49f5-97e6-de141da9ca44/vbuild/ducktape/results/final/report.html |
dotnwat
reviewed
Mar 23, 2024
|
/ci-repeat 10 |
nvartolomei
added a commit
to nvartolomei/redpanda
that referenced
this pull request
Mar 25, 2024
VerifiableConsumer is KIP-320 compliant now. At least to the degree the java kafka client is. This will facilitates testing of the redpanda implementation of KIP-320 in group recovery (redpanda-data#17260) and data loss handling when write caching is enabled.
nvartolomei
force-pushed
the
nv/kafka-group-recover-leader-epoch
branch
from
8e82687
to
0ed5c6b
Compare
VerifiableConsumer is KIP-320 compliant now. At least to the degree the java kafka client is. This will facilitates testing of the redpanda implementation of KIP-320 in group recovery (redpanda-data#17260) and data loss handling when write caching is enabled.
This tests consumer group commits. The test also shows a bug in which leader_offset is reset after cluster restart. This is fixed in a subsequent commit.
This was discovered while testing write caching feature. After leadership change or node restart we would reply with default field value `-2147483648` which breaks the KIP-320 logic. `check_leader_epoch` in redpanda treats negative epoch values as "not set" and, I believe, franz-go behaves the same. As result, KIP-320 fencing is not being applied and the client ends up with `OFFSET_OUT_OF_RANGE` error.
nvartolomei
force-pushed
the
nv/kafka-group-recover-leader-epoch
branch
from
0ed5c6b
to
501b9d3
Compare
|
/backport v23.3.x |
|
/backport v23.2.x |
vbotbuildovich
pushed a commit
to vbotbuildovich/redpanda
that referenced
this pull request
Mar 26, 2024
VerifiableConsumer is KIP-320 compliant now. At least to the degree the java kafka client is. This will facilitates testing of the redpanda implementation of KIP-320 in group recovery (redpanda-data#17260) and data loss handling when write caching is enabled. (cherry picked from commit 9316309)
vbotbuildovich
pushed a commit
to vbotbuildovich/redpanda
that referenced
this pull request
Mar 26, 2024
VerifiableConsumer is KIP-320 compliant now. At least to the degree the java kafka client is. This will facilitates testing of the redpanda implementation of KIP-320 in group recovery (redpanda-data#17260) and data loss handling when write caching is enabled. (cherry picked from commit 9316309)
6 tasks
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
From my understanding, this can cause a problem only when write caching is enabled.
It could also apply to ACKS=1 in an edge case but haven't thought it through. We make data available only after majority replicated so it’s very unlikely for a truncation to happen after that and trigger KIP-320
This was discovered while testing write caching feature. After leadership change or node restart we would reply with default field value
-2147483648which breaks the KIP-320 logic.check_leader_epochin redpanda treats negative epoch values as "not set" and, I believe, franz-go behaves the same.As result, KIP-320 fencing is not being applied and the client ends up with
OFFSET_OUT_OF_RANGEerror.Backports Required
Release Notes