-
Notifications
You must be signed in to change notification settings - Fork 600
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
Improved handling of truncation with ACKS=1 #16475
Improved handling of truncation with ACKS=1 #16475
Conversation
71b489c
to
46c5f29
Compare
/dt |
@@ -2013,7 +2013,7 @@ consensus::do_append_entries(append_entries_request&& r) { | |||
|
|||
// section 3 | |||
if (request_metadata.prev_log_index < last_log_offset) { | |||
if (unlikely(request_metadata.prev_log_index < _commit_index)) { | |||
if (unlikely(request_metadata.prev_log_index < last_visible_index())) { |
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.
so IIUC the problem is with follower fetching + acks=1 because, on a follower the log can be truncated below high watermark (because of committed offset check) say during recovery and the subsequent read from the follower may result in an out of range read, is that correct?
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.
exactly
46c5f29
to
681fbb5
Compare
@@ -2013,7 +2013,7 @@ consensus::do_append_entries(append_entries_request&& r) { | |||
|
|||
// section 3 | |||
if (request_metadata.prev_log_index < last_log_offset) { | |||
if (unlikely(request_metadata.prev_log_index < _commit_index)) { | |||
if (unlikely(request_metadata.prev_log_index < last_visible_index())) { |
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.
Should we use last_visible_index()
in line 2020 as well? (not entirely understanding its significance, but seems logical...)
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.
makes sense, i will change this
Signed-off-by: Michal Maslanka <michal@redpanda.com>
If an offset was already visible a follower must not be allowed to truncate it as it may lead to a situation in which an offset is visible and not readable. Visible batches has the same replication guarantees as committed batches as leader still waits for the majority to acknowledge message at given offset before making it visible to the readers. This makes it possible not to truncate offsets which were previously visible. Signed-off-by: Michal Maslanka <michal@redpanda.com>
Added test checking if an offset that is visible on the leader is not truncated on the followers. Signed-off-by: Michal Maslanka <michal@redpanda.com>
681fbb5
to
8975291
Compare
/backport v23.3.x |
/backport v23.2.x |
Failed to create a backport PR to v23.2.x branch. I tried:
|
If an offset was already visible a follower must not be allowed to
truncate it as it may lead to a situation in which an offset is visible
and not readable.
Visible batches has the same replication guarantees as committed batches
as leader still waits for the majority to acknowledge message at given
offset before making it visible to the readers. This makes it possible
not to truncate offsets which were previously visible.
Backports Required
Release Notes
Improvements