-
Notifications
You must be signed in to change notification settings - Fork 589
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Kafka: Add support for the delete-records API #10061
Kafka: Add support for the delete-records API #10061
Conversation
Added more ducktape tests |
wondering if franz-go has some delete records test, or if the librdkafka test suite should be enabled for this or some other external-API project that exercises this path for edge case detection. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks like lots of tests are failing, perhaps related to the timeout change in the PR.
bc82906
to
4d086ba
Compare
Changes in force-push
|
4d086ba
to
8a2d84b
Compare
Leaving a comment here about the proposed testing plan. All testing will be done in Ducktape, desired scenarios to test are:
|
8a2d84b
to
a765617
Compare
Test failures look like:
Note this must indicate a bug in the changes I've made to log_eviction_stm, when handling GC events from storage. |
1626948
to
ebb4b29
Compare
Changes in force-push
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There's still some things I don't understand, so I'll need to come back to it.
ebb4b29
to
3a05354
Compare
Changes in force-push
|
3a05354
to
2fb1f65
Compare
Changes in force-push
|
2fb1f65
to
9dd1e60
Compare
b32b63c
to
7896fbb
Compare
7896fbb
to
25cd9e6
Compare
25cd9e6
to
7a4e047
Compare
- This commit modifies the log_eviction_stm to be a proper stm that will scan the underlying log for new special batches of type 'prefix_truncate'. - These new special batches are indicators to modify the start offset. Since this is replicated to peers, eventually all peers will modify their respective start offsets as well. - There is a new background processing fiber added to this class as well that attempts to write a raft snapshot , reaping as much data as possible as close to the current start offset. - The class is a subclass of persisted_stm and persists to the kvstore its last applied offset and the current start offset. In the case of failures these pieces of information can be used to startup from the last processed offset.
- The kafka layer presents the prefix_truncate abstraction, it performs bounds checking with the given kafka offset and translates this to a rp model::offset before invoking cluster::prefix_truncate , which will boil down to replicating the prefix truncate special batch.
- This stm has a conditional in its last_stable_offset() method that returns an invalid offset in the case it hasn't completed bootstrapping. - The issue is that this bootstrap phase isn't considered finished after bootstrapping from apply_snapshot(). This would cause other stms to pause thinking the rm_stm had work to do at an offset at 0, causing that other stm to timeout and fail processing of said event. - Solution is simple, to set `_boostrap_committed_offset`within the `apply_snapshot()` method - Fixes: redpanda-data#11131 - Fixes: redpanda-data#11130
- relevent kafka git commit: e7acf3c
- Adds support for the DeleteRecords API
- Now that the start offset is not an independent concept across all nodes its desired to ensure the leader node has cought up with previous leader with respect to processing of prefix truncate special batches before returning the start offset. - This avoids returning a stale start_offset in the case leadership has recently changed and the log_eviction_stm hasn't yet caught up.
7a4e047
to
e029aa5
Compare
CI failures
Investigating a leak seen in |
/ci-repeat 1 |
/ci-repeat 1 |
/ci-repeat 1 |
This PR adds the delete-records feature to redpanda. This feature allows a kafka client to truncate data from a topic/partition at a given offset. To support this in redpanda two non-trivial tasks were implemented:
Note, as of this branch delete-records requests for cloud enabled topics will be rejected. Work on supporting this is slated to be completed in a follow up PR,
which depends on a currently still in review PR#9994Backports Required
Release Notes
Features