Reduce spurious replication catchup #16555
Conversation
erikjohnston
force-pushed
the
erikj/reduce_spurious_fetches
branch
from
2bb6b70
to
b43fc5e
Compare
synapse/replication/tcp/handler.py
Outdated
| # If the position token matches our current token then we're up to date | ||
| # and there's nothing to do. Otherwise, fetch all updates between then | ||
| # and now. |
There was a problem hiding this comment.
| # If the position token matches our current token then we're up to date | |
| # and there's nothing to do. Otherwise, fetch all updates between then | |
| # and now. | |
| # If the incoming position is at least our current position then we're | |
| # up to date and there's nothing to do. Otherwise, fetch all updates | |
| # between then and now. |
There was a problem hiding this comment.
Example: I think the stream is at position 10.
I receive POSITION 4 8.
Uh oh, I might have missed stream entries 5, 6, 7 and 8. Need to rescan for them.
(Here prev < next < current.)
There was a problem hiding this comment.
Ah, no. POSITION 4 8 means that the new token for that instance should be set to 8, and nothing has happened between 4 and 8 from that instance. (The reason for this is that normally we'd just get a stream of RDATA from the instance, which implicitly bumps the token. If for some reason the token has advanced without any updates to send, it sends a POSITION, hence why it gives the range where things have not happened).
There was a problem hiding this comment.
| # If the position token matches our current token then we're up to date | |
| # and there's nothing to do. Otherwise, fetch all updates between then | |
| # and now. | |
| # If the incoming previous position is less than our current position | |
| # then we're up to date and there's nothing to do. Otherwise, fetch | |
| # all updates between then and now. |
Maybe?
synapse/replication/tcp/handler.py
Outdated
| # Note: We have to check that `current_token` is within the range, to | ||
| # handle the case where the stream gets "reset" (e.g. for `caches` and | ||
| # `typing` after the writer's restart). |
There was a problem hiding this comment.
| # Note: We have to check that `current_token` is within the range, to | |
| # handle the case where the stream gets "reset" (e.g. for `caches` and | |
| # `typing` after the writer's restart). | |
| # Note: We also have to check that `current_token` is at least the | |
| # previous position, to handle the case where the stream gets "reset" | |
| # (e.g. for `caches` and `typing` after the writer's restart). |
There was a problem hiding this comment.
Example: I think the stream is at position 10.
I receive POSITION 12 15.
Uh oh, I might have missed stream entries 11, 12, 13, 14, and 15. Need to rescan for them.
(Here current < prev < next.)
There was a problem hiding this comment.
Uh oh, I might have missed stream entries 11, 12, 13, 14, and 15. Need to rescan for them.
You might have missed entries 11 and 12.
There was a problem hiding this comment.
Does POSITION need some better documentation somewhere (either https://matrix-org.github.io/synapse/develop/development/synapse_architecture/streams.html or maybe in the code?) describing how it works? I think I was also under the impression that it told you were it had updates, not where it jumped to without updates.
There was a problem hiding this comment.
https://matrix-org.github.io/synapse/develop/tcp_replication.html#position-s probably needs to be updated too
There was a problem hiding this comment.
(Not blocking this PR, but would appreciate a follow-up or at least an issue.)
There was a problem hiding this comment.
#16560 since its a Friday afternoon and I'm liable to forget to follow up otherwise
There was a problem hiding this comment.
| # Note: We have to check that `current_token` is within the range, to | |
| # handle the case where the stream gets "reset" (e.g. for `caches` and | |
| # `typing` after the writer's restart). | |
| # Note: We also have to check that `current_token` is at least the | |
| # new position, to handle the case where the stream gets "reset" | |
| # (e.g. for `caches` and `typing` after the writer's restart). |
| # Note: We have to check that `current_token` is within the range, to | ||
| # handle the case where the stream gets "reset" (e.g. for `caches` and | ||
| # `typing` after the writer's restart). | ||
| missing_updates = not (cmd.prev_token <= current_token <= cmd.new_token) |
There was a problem hiding this comment.
Sanity check: are the inequalities correct here? E.g. should one of them be < instead of <=?
There was a problem hiding this comment.
Good point that it looks weird. But I think they're right as we're comparing "upper bounds"
Co-authored-by: Patrick Cloke <clokep@users.noreply.github.com>
The
POSITIONcommand includes two tokens, the "prev" and "new" tokens. The "new" token is what we should set the current token for the instance to be, and the "prev" token was where it was previously (i.e. the instance produced no rows between the "prev" and "new" tokens).This means that we can safely relax the condition to only check for missing updates if the current token for the writer is strictly less than the "prev" token.
A common case is receiving something like
POSITIONS event_persister1 events 15 16, which indicates the writer advanced their events stream token from 15 to 16 (usually as a response to another instance persisting an event with stream ID 16). Usually, the other instances would already have inferred thatevent_persister1must have advanced their token, so thecurrent_tokenwould already be set to 16, thus triggering a lookup for missing updates between tokens 16 (cmd.new_token) and 16 (current_token), which is silly.We also move the logging back into the loop so that we don't log in the common case.