Track unhealthy heartbeat + pause job fetching when unhealthy#1321
Open
brandur wants to merge 2 commits into
Open
Track unhealthy heartbeat + pause job fetching when unhealthy#1321brandur wants to merge 2 commits into
brandur wants to merge 2 commits into
Conversation
This one's driven by another issue flagged out of the active rescue system: as currently implemented, the producer's heartbeat produces an error if it fails, but there's no additional feedback. So if a producer were to chronically start failing its heartbeats, it'd be possible for the `JobRescuer` (were its rescue queries to keep working in this case, which is not certain) to start incorrectly rescuing jobs as producers started to look inactive. This could then result in duplicate jobs. This change doesn't fully address that problem, but partly remediates it by having each producer track whether its heartbeat is unhealthy. If found to be unhealthy, the producer stops fetching new jobs because if a simple producer update is failing, presumably the rest of the database is also experiencing significant trouble. In this case jobs running in an unhealthy producer could still be rescued, but at least they wouldn't start work again as their producer is unhealthy, thus avoiding a potentially runaway feedback loop.
This takes the functionality that tracks producer unhealthy heartbeats a step further by having `JobRescuer` pause in case any of its producers are unhealthy. The end goal is the same: don't accidentally rescue jobs where a producer has fallen out of sync because it can't write its heartbeats to the database. As before, this takes us further in the direction of resilience, but it's still not a perfect patch. The `JobRescuer` is only running on the client currently elected leader, so it requires that producers on that client be unhealthy for the pause to be initiated. If a producer on a client elsewhere is unhealthy, it won't be picked up. However, this should be okay in most situations because if one producer is unable to write heartbeats, there's a reasonable chance that all producers are having trouble doing it.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This one's driven by another issue flagged out of the active rescue
system: as currently implemented, the producer's heartbeat produces an
error if it fails, but there's no additional feedback. So if a producer
were to chronically start failing its heartbeats, it'd be possible for
the
JobRescuer(were its rescue queries to keep working in this case,which is not certain) to start incorrectly rescuing jobs as producers
started to look inactive. This could then result in duplicate jobs.
This change doesn't fully address that problem, but partly remediates it
by having each producer track whether its heartbeat is unhealthy. If
found to be unhealthy, the producer stops fetching new jobs because if a
simple producer update is failing, presumably the rest of the database
is also experiencing significant trouble. In this case jobs running in
an unhealthy producer could still be rescued, but at least they wouldn't
start work again as their producer is unhealthy, thus avoiding a
potentially runaway feedback loop.