Linearizable barrier improvements #11939
Conversation
|
|
1 similar comment
|
|
When linearizable barrier is requested we want follower to flush its log to make sure that all possible entries are committed with traditional raft semantics. Added handling of flushing log on the follower if leader requested it and append entries request is empty. Signed-off-by: Michal Maslanka <michal@redpanda.com>
When linearizable barrier is set we want to move committed offset forward. In this case followers must flush their offsets to allow leader committing its entries. Signed-off-by: Michal Maslanka <michal@redpanda.com>
For the STM linearizable barrier to make sense we must wait for the offset to be applied to the stm. Otherwise the linearizable barrier gives no guarantees about the state machine state. Signed-off-by: Michal Maslanka <michal@redpanda.com>
In order to prevent contention implemented sharing linearizable barrier result between contended callers. Instead of calling linearizable barrier multiple times a caller will wait for the result of a barrier that is already being executed. This doesn't change the current semnatics of linearizable barrier as either way a caller must check the returned offset if they want to wait for the whole history to be applied. Sharing results helps in a situation where multiple parallel fibers try to setup linearizable barrier. Signed-off-by: Michal Maslanka <michal@redpanda.com>
| } | ||
|
|
||
| // wait for the returned offset to be applied | ||
| return wait(r.value(), timeout).then([r] { | ||
| return result<model::offset>(r.value()); | ||
| return wait(r.value(), timeout).then([this, r] { |
There was a problem hiding this comment.
I think there may be some undesirable side effects to this optimization.. In a happy path, the shared future resolves when the wait() succeeds, consider the following sequence of actions..
- linearizable_barrier at offset o
- usual replicate() at offset o + 1
- linearizable_barrier at offset o + 2
(3) can potentially resolve with the same shared future as (1), we have a problem? Normally I don't think this is a problem if we validate the offset returned from linearizable_barrier (3) is > o + 1 but we don't in many places. Think we have this pattern in topics_frontend.. eg: if we create too many topics back to back and topics stm may not have applied the changes by the time barrier returns.
There was a problem hiding this comment.
so the barrier semantics was like that before i.e. it could always race with the replicate(), this is why i decided to it this way. This is why we return an offset that is confirmed
There was a problem hiding this comment.
so the barrier semantics was like that before
But 3bcf038 tightens that behavior but this optimization brings it back, no?
it could always race with the replicate()
just to be clear I'm talking about read-your-own-writes here, so its not just any replicate, its the replicate before the barrier.
There was a problem hiding this comment.
you are right it may happen that the barrier called after the replicate will return, the value of previous barrier, it won't hurt in this case as that was the previous semantics, but it is definitely confusing.
|
/backport v23.1.x |
|
Failed to run cherry-pick command. I executed the commands below: |
Improved the way how linearizable barrier is handled
Fixes: #11062
Backports Required
Release Notes
Improvements