Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Make connection killing resilient to MySQL hangs #14500

Merged
merged 9 commits into from
Mar 4, 2024

Conversation

arthurschreiber
Copy link
Contributor

@arthurschreiber arthurschreiber commented Nov 9, 2023

Description

This fixes some issues around *Conn.Kill that can be encountered when MySQL "hangs" (e.g. either by sending it a SIGSTOP signal or when MySQL is writing a core dump file after a crash).

Kill has no context / timeout support at all. This means that when MySQL hangs, and some other code tries to send the KILL <id> statement to MySQL (e.g. due to setDeadline or because the code tries to call Kill directly), the Kill function is just going to hang as well.

I added a new function KillWithContext that allows passing in a Context object and correctly honors cancellation. I replaced setDeadline with direct calls to KillWithContext, with a 5 second timeout. I don't think a 5 second timeout actually makes any sense - but setDeadline intended to use a timeout of 2*elapsed + 5*time.Second (which never actually worked). Because KILL <id> on MySQL is supposed to return instantly, I think a much lower timeout would be sufficient.

In case the context passed to KillWithContext is canceled / timed out, there's nothing we can do - the client side connection on which we want to kill the executing statement was already closed anyway, and sending the KILL <id> statement is more or less best effort. So we just close the kill connection and return.

TODO

  • I want to go through all callers of Kill and either switch them over to pass a Context to higher level methods like Exec, or switch them to use KillWithContext instead.
  • This also requires more tests. Existing tests are all passing, but they didn't cover the "broken" cases.

Related Issue(s)

Checklist

  • "Backport to:" labels have been added if this change should be back-ported
  • Tests were added or are not required
  • Did the new or modified tests pass consistently locally and on the CI
  • Documentation was added or is not required

Deployment Notes

Signed-off-by: Arthur Schreiber <arthurschreiber@github.com>
Signed-off-by: Arthur Schreiber <arthurschreiber@github.com>
Copy link
Contributor

vitess-bot bot commented Nov 9, 2023

Review Checklist

Hello reviewers! 👋 Please follow this checklist when reviewing this Pull Request.

General

  • Ensure that the Pull Request has a descriptive title.
  • Ensure there is a link to an issue (except for internal cleanup and flaky test fixes), new features should have an RFC that documents use cases and test cases.

Tests

  • Bug fixes should have at least one unit or end-to-end test, enhancement and new features should have a sufficient number of tests.

Documentation

  • Apply the release notes (needs details) label if users need to know about this change.
  • New features should be documented.
  • There should be some code comments as to why things are implemented the way they are.
  • There should be a comment at the top of each new or modified test to explain what the test does.

New flags

  • Is this flag really necessary?
  • Flag names must be clear and intuitive, use dashes (-), and have a clear help text.

If a workflow is added or modified:

  • Each item in Jobs should be named in order to mark it as required.
  • If the workflow needs to be marked as required, the maintainer team must be notified.

Backward compatibility

  • Protobuf changes should be wire-compatible.
  • Changes to _vt tables and RPCs need to be backward compatible.
  • RPC changes should be compatible with vitess-operator
  • If a flag is removed, then it should also be removed from vitess-operator and arewefastyet, if used there.
  • vtctl command output order should be stable and awk-able.

@vitess-bot vitess-bot bot added NeedsDescriptionUpdate The description is not clear or comprehensive enough, and needs work NeedsIssue A linked issue is missing for this Pull Request NeedsWebsiteDocsUpdate What it says labels Nov 9, 2023
@github-actions github-actions bot added this to the v19.0.0 milestone Nov 9, 2023
@arthurschreiber arthurschreiber added Component: Query Serving Type: Bug and removed NeedsDescriptionUpdate The description is not clear or comprehensive enough, and needs work NeedsWebsiteDocsUpdate What it says NeedsIssue A linked issue is missing for this Pull Request labels Nov 9, 2023
@harshit-gangal harshit-gangal added the Benchmark me Add label to PR to run benchmarks label Nov 20, 2023
Copy link
Contributor

vitess-bot bot commented Nov 20, 2023

Hello! 👋

This Pull Request is now handled by arewefastyet. The current HEAD and future commits will be benchmarked.

You can find the performance comparison on the arewefastyet website.

Comment on lines 166 to 169
resultChan := make(chan *sqltypes.Result, 1)
errChan := make(chan error, 1)

if done != nil {
close(done)
wg.Wait()
startTime := time.Now()
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

making channel on runtime for every call seems expensive to me.
I have added Benchmark me label to it as well.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is no worse than the current code, which already creates a channel and a waitgroup. The current code, however, is very wasteful. So I think we can improve this to make this even less costly! Let me try...

@vmg
Copy link
Collaborator

vmg commented Nov 20, 2023

@arthurschreiber: can you apply 996e652 to this PR? It significantly reduces all allocations we perform and should make us faster than the previous code, while still being correct

@arthurschreiber
Copy link
Contributor Author

@vmg Thanks! I'm on it. 🙇‍♂️

@arthurschreiber
Copy link
Contributor Author

@vmg Just for my understanding, the improvements come from not copying the current query string, and by creating one channel instead of two?

@vmg
Copy link
Collaborator

vmg commented Nov 20, 2023

Yeah, the current string is obviously unrelated to your PR, I just noticed that we were using atomic.Value which is a very rough (type unsafe) API that has been superseded by atomic.Pointer.

The changes in the actual connection path boil down to always creating a single channel instead of two. I also noticed we were fetching the current time twice (one for the metrics and one for the potential Kill call) so I unified that. Overall I think this is a huge improvement. The previous setDeadline was expensive and definitely showing up in profiles, and with this new code we're gonna see half as many allocations, because we only have a channel per request now and previously we had a channel and a WaitGroup.

There are ways to make this zero allocation but I don't think we should attempt that for now.

Signed-off-by: Vicent Marti <vmg@strn.cat>
@arthurschreiber
Copy link
Contributor Author

I worked on tests to fully cover this code, but the tests are using fakesqldb and that code has other problems that make it hard to write proper tests. 🫠 I will open another PR to fix the issues in fakesqldb, and then will add tests here.

Copy link
Contributor

This PR is being marked as stale because it has been open for 30 days with no activity. To rectify, you may do any of the following:

  • Push additional commits to the associated branch.
  • Remove the stale label.
  • Add a comment indicating why it is not stale.

If no action is taken within 7 days, this PR will be closed.

@github-actions github-actions bot added the Stale Marks PRs as stale after a period of inactivity, which are then closed after a grace period. label Dec 28, 2023
Copy link
Contributor

github-actions bot commented Jan 4, 2024

This PR was closed because it has been stale for 7 days with no activity.

@github-actions github-actions bot removed the Stale Marks PRs as stale after a period of inactivity, which are then closed after a grace period. label Feb 22, 2024
Signed-off-by: Daniel Joos <danieljoos@github.com>
Copy link
Collaborator

@vmg vmg left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks great. Thanks for adding the tests!

@vmg
Copy link
Collaborator

vmg commented Mar 4, 2024

I think the error in CI is related to the changes here, but looking at the test, it may just not be properly written/testing the right thing. Can you give it a look @arthurschreiber?

@arthurschreiber
Copy link
Contributor Author

@vmg I kicked the tests off again. I could not see any relationship between the failures and the changes in this PR - did I miss something? 🤔

@arthurschreiber
Copy link
Contributor Author

Oh, there is a different set of CI statuses on the commit and on the PR? Weird. I'm taking a look.

@arthurschreiber
Copy link
Contributor Author

Ok, so from what I understand the failures in the mysql57 unit test build are all coming from the same test case?(TestSerializeTransactionsSameRow_ConcurrentTransactions). Digging into what's going on there.

…/fix-conn-kill-hang

Signed-off-by: Arthur Schreiber <arthurschreiber@github.com>
Signed-off-by: Arthur Schreiber <arthurschreiber@github.com>
@arthurschreiber
Copy link
Contributor Author

arthurschreiber commented Mar 4, 2024

I think I figured it out. The test case had an implicit dependency on the "incorrect" behaviour of fakesqldb.DB where only a single connection could be executing a query (and all other connections would have to wait implicitly for the callbacks of that first query to have finished executing). With that behaviour removed, the test case was failing.

I fixed it by making all 3 queries / transactions wait explicitly for the allQueriesPending channel.

@vmg vmg merged commit 7a2af6f into vitessio:main Mar 4, 2024
102 checks passed
@vmg
Copy link
Collaborator

vmg commented Mar 4, 2024

Looks great! I figured the test was making wrong assumptions. Thanks again @arthurschreiber

@arthurschreiber arthurschreiber deleted the arthur/fix-conn-kill-hang branch March 4, 2024 12:06
@GrahamCampbell
Copy link
Contributor

To be backported to v19?

GrahamCampbell pushed a commit to GrahamCampbell/vitess that referenced this pull request Mar 6, 2024
Signed-off-by: Arthur Schreiber <arthurschreiber@github.com>
Signed-off-by: Vicent Marti <vmg@strn.cat>
Signed-off-by: Daniel Joos <danieljoos@github.com>
Co-authored-by: Vicent Marti <vmg@strn.cat>
Co-authored-by: Daniel Joos <danieljoos@github.com>
@deepthi
Copy link
Member

deepthi commented Mar 6, 2024

To be backported to v19?

Sorry we missed this. The release is going out today. In future the way to get an auto-backport is to add a backport label before the PR is merged. I realize you don't have the permissions to do that, but @arthurschreiber does.

@GrahamCampbell
Copy link
Contributor

We can probs just add the label to my 2nd PR, if it's wanted in 18.0 or 17.0. I don't personally care to see this backported earlier than 19.0. ;)

@frouioui frouioui modified the milestones: v19.0.0, v20.0.0 Mar 6, 2024
andyedison pushed a commit to github/vitess-gh that referenced this pull request Apr 18, 2024
Signed-off-by: Arthur Schreiber <arthurschreiber@github.com>
Signed-off-by: Vicent Marti <vmg@strn.cat>
Signed-off-by: Daniel Joos <danieljoos@github.com>
Co-authored-by: Vicent Marti <vmg@strn.cat>
Co-authored-by: Daniel Joos <danieljoos@github.com>
arthurschreiber added a commit to github/vitess-gh that referenced this pull request Apr 23, 2024
Make connection killing resilient to MySQL hangs (vitessio#14500)
@arthurschreiber arthurschreiber added Backport to: release-17.0 Backport to: release-18.0 Needs to be back ported to release-18.0 labels May 30, 2024
@arthurschreiber
Copy link
Contributor Author

Mh. I hoped adding backport labels will open backport PRs, but it doesn't look like that's working. :/ I'll open the backport PRs manually then.

@GrahamCampbell
Copy link
Contributor

I don't think this was ever backported to v19 either?

@GrahamCampbell
Copy link
Contributor

So I'm sure sure the vitess team will accept a v17 or v18 backport. My v19 backport was rejected: #15411.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Backport to: release-18.0 Needs to be back ported to release-18.0 Benchmark me Add label to PR to run benchmarks Component: Query Serving Type: Bug
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Bug Report: VTTablet & VTGate routing traffic to hung MySQL server
7 participants