Update LOCK_WAIT_TIMEOUT_DELTA #60
Merged
Conversation
This file contains 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
jordanwheeler
approved these changes
Oct 11, 2018
bbuchalter
force-pushed
the
bbuchalter-patch-1
branch
from
d84fa2c to
f94f965
Compare
Per #58 (comment) With a -2 there (lock wait timeout for the lhm session two second below anybody else), it means that in the case of a queue of clients waiting to grab the lock, the lhm client is going to be the one giving up first. Which is why we had so many issues completing this lhm/ptosc on collects (and it will likely happen again if we had to run another one on that table): Shopify/datastores#2803 We first decided to add this delta after an incident in 2014, where we were still using the default lock wait timeout for the version of mysql we were using at that time (5.5): One year. Looking at that from another perspective, between the LHM client getting the lock, instead of regular web/job client, I'd rather have the LHM succeeding: A single web or job worker timing out is no big deal. It's not like if we are risking all shopify to lock down by increasing this value: That was the case in 2013/2014, where clients waited to acquire the lock forever, not like now, for ten seconds.
bbuchalter
force-pushed
the
bbuchalter-patch-1
branch
from
f94f965 to
96069db
Compare
|
Despite what buildkite says, the build is passing. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Per #58 (comment)
With a
-2there (lock wait timeout for the lhm session two second below anybody else), it means that in the case of a queue of clients waiting to grab the lock, the lhm client is going to be the one giving up first.Which is why we had so many issues completing this lhm/ptosc on collects (and it will likely happen again if we had to run another one on that table): Shopify/datastores#2803.
We first decided to add this delta after an incident in 2014, where we were still using the default lock wait timeout for the version of mysql we were using at that time (5.5): One year.
Looking at that from another perspective, between the LHM client getting the lock, instead of regular web/job client, I'd rather have the LHM succeeding: A single web or job worker timing out is no big deal.
It's not like if we are risking all shopify to lock down by increasing this value: That was the case in 2013/2014, where clients waited to acquire the lock forever, not like now, for ten seconds.