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

Associate each region with an independent backoffer (#17568) #17585

Merged
merged 3 commits into from
Jun 6, 2020

Conversation

sre-bot
Copy link
Contributor

@sre-bot sre-bot commented Jun 2, 2020

cherry-pick #17568 to release-4.0


Signed-off-by: Xintao hunterlxt@live.com

What problem does this PR solve?

Issue Number: close tikv/tikv#7853

Problem Summary:
The backoffer of the boRegionMiss has a backoff mechanism with a starting time of 2ms and a maximum of 500ms. After log verification, a SQL command will share the same backoffer, that is, if multiple regions return epoch not match error, then the backoffer will quickly rise to 500ms. It is easy to exceed the preset time limit of 40s, causing SQL errors on the client.

What is changed and how it works?

What's Changed: Add a function to get Backoffer

How it Works: Use a Map to store backoffer with specific region id

Related changes

  • Need to cherry-pick to the release branch

Check List

Tests

  • Manual test (add detailed scripts or steps below)
  1. split table x between (0) and (10000000) regions 400
  2. select count(*) from x

Before this PR, the SQL usually returns region is unavailable

Side effects

No

Release note

  • Assign different Backoffer for each region to avoid the SQL command timeout issue when multiple region requests fail at the same time

Signed-off-by: sre-bot <sre-bot@pingcap.com>
@sre-bot
Copy link
Contributor Author

sre-bot commented Jun 2, 2020

/run-all-tests

Copy link
Contributor

@lysu lysu left a comment

Choose a reason for hiding this comment

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

LGTM

@lysu lysu added the status/LGT1 Indicates that a PR has LGTM 1. label Jun 3, 2020
Copy link
Contributor

@lzmhhh123 lzmhhh123 left a comment

Choose a reason for hiding this comment

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

LGTM

@lzmhhh123 lzmhhh123 added status/LGT2 Indicates that a PR has LGTM 2. and removed status/LGT1 Indicates that a PR has LGTM 1. labels Jun 3, 2020
@zz-jason zz-jason added the status/can-merge Indicates a PR has been approved by a committer. label Jun 3, 2020
@sre-bot
Copy link
Contributor Author

sre-bot commented Jun 3, 2020

/run-all-tests

@sre-bot
Copy link
Contributor Author

sre-bot commented Jun 3, 2020

@sre-bot merge failed.

@bb7133 bb7133 modified the milestones: v4.0.1, v4.0.2 Jun 6, 2020
@zz-jason
Copy link
Member

zz-jason commented Jun 6, 2020

/merge

@sre-bot
Copy link
Contributor Author

sre-bot commented Jun 6, 2020

Your auto merge job has been accepted, waiting for:

  • 17694
  • 17680
  • 17681
  • 17648
  • 17705
  • 17719
  • 17651
  • 17636
  • 17536
  • 17570

@sre-bot
Copy link
Contributor Author

sre-bot commented Jun 6, 2020

/run-all-tests

@sre-bot sre-bot merged commit b5b4da0 into pingcap:release-4.0 Jun 6, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
component/tikv status/can-merge Indicates a PR has been approved by a committer. status/LGT2 Indicates that a PR has LGTM 2. type/enhancement The issue or PR belongs to an enhancement. type/4.0-cherry-pick
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants