Reduce log spam when running multiple event persisters (#12610)

This commit is contained in:
Erik Johnston 2022-05-05 10:20:23 +01:00 committed by GitHub
parent 2d74a8c178
commit c0379d6e5b
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
3 changed files with 17 additions and 2 deletions

1
changelog.d/12610.misc Normal file
View File

@ -0,0 +1 @@
Reduce log spam when running multiple event persisters.

View File

@ -537,7 +537,7 @@ class ReplicationCommandHandler:
# Ignore POSITION that are just our own echoes
return
logger.info("Handling '%s %s'", cmd.NAME, cmd.to_line())
logger.debug("Handling '%s %s'", cmd.NAME, cmd.to_line())
self._add_command_to_stream_queue(conn, cmd)
@ -567,6 +567,11 @@ class ReplicationCommandHandler:
# between then and now.
missing_updates = cmd.prev_token != current_token
while missing_updates:
# Note: There may very well not be any new updates, but we check to
# make sure. This can particularly happen for the event stream where
# event persisters continuously send `POSITION`. See `resource.py`
# for why this can happen.
logger.info(
"Fetching replication rows for '%s' between %i and %i",
stream_name,

View File

@ -204,6 +204,15 @@ class ReplicationStreamer:
# turns out that e.g. account data streams share
# their "current token" with each other, meaning
# that it is *not* safe to send a POSITION.
# Note: `last_token` may not *actually* be the
# last token we sent out in a RDATA or POSITION.
# This can happen if we sent out an RDATA for
# position X when our current token was say X+1.
# Other workers will see RDATA for X and then a
# POSITION with last token of X+1, which will
# cause them to check if there were any missing
# updates between X and X+1.
logger.info(
"Sending position: %s -> %s",
stream.NAME,