Lightning: increase backoff if split fails

[mittalrishabh]

What problem does this PR solve?

Issue Number: close #49517

Problem Summary:
Lightning job is failing intermittently after enable BR on prod clusters because of batch split failure. During the backup process, BR temporarily disables the schedulers for a period of 1-2 minutes. However, the Lightning job, which does not have a backoff mechanism, continues to retry the process for up to 5 times without pausing or spacing out the retries.

What changed and how does it work?

i am adding a exponential back off before each retry and now it will retry upto 930 seconds before if fails the job

Check List

Tests

• Unit test
• Integration test
• Manual test (add detailed scripts or steps below)
• No need to test

  • I checked and no code files have been changed.

Side effects
NO

• Performance regression: Consumes more CPU
• Performance regression: Consumes more Memory
• Breaking backward compatibility

Documentation
NO

• Affects user behaviors
• Contains syntax changes
• Contains variable changes
• Contains experimental features
• Changes MySQL compatibility

Release note

Please refer to Release Notes Language Style Guide to write a quality release note.

None

[ti-chi-bot]

Hi @mittalrishabh. Thanks for your PR.

I'm waiting for a pingcap member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[tiprow]

Hi @mittalrishabh. Thanks for your PR.

PRs from untrusted users cannot be marked as trusted with /ok-to-test in this repo meaning untrusted PR authors can never trigger tests themselves. Collaborators can still trigger tests on the PR using /test all.

I understand the commands that are listed here.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[lance6716]

/ok-to-test

[codecov]

Codecov Report

Attention: Patch coverage is 20.00000% with 8 lines in your changes missing coverage. Please review.

Project coverage is 67.2674%. Comparing base (2065be4) to head (dd863e2).
Report is 2326 commits behind head on master.

Additional details and impacted files

@@               Coverage Diff                @@
##             master     #49518        +/-   ##
================================================
- Coverage   71.9600%   67.2674%   -4.6926%     
================================================
  Files          1438       2558      +1120     
  Lines        345749     849351    +503602     
================================================
+ Hits         248801     571337    +322536     
- Misses        76712     254230    +177518     
- Partials      20236      23784      +3548     

Flag	Coverage Δ
integration	37.2742% <20.0000%> (?)
unit	79.2959% <20.0000%> (+7.3358%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

Components	Coverage Δ
dumpling	73.6130% <ø> (+17.3001%)	⬆️
parser	∅ <ø> (∅)
br	70.6383% <20.0000%> (+18.9987%)	⬆️

[D3Hunter]

some background about this pr: #49517 (comment)

[D3Hunter]

there are already backoff in region split， just not long enough

tidb/br/pkg/lightning/backend/local/localhelper.go

Lines 171 to 174 in 0719329

	waitTime *= 2
	if waitTime > retrySplitMaxWaitTime {
	waitTime = retrySplitMaxWaitTime
	}

[mittalrishabh]

there are already backoff in region split， just not long enough

tidb/br/pkg/lightning/backend/local/localhelper.go

Lines 171 to 174 in 0719329

	waitTime *= 2
	if waitTime > retrySplitMaxWaitTime {
	waitTime = retrySplitMaxWaitTime
	}

It is only for 4 seconds. BR can suspend split from 60 seconds to 10 min. And i don't want to increase this backoff time as it is going to add backoff in each region split which will be very expensive.

[mittalrishabh]

can you please review this PR

[lance6716]

rest lgtm

[mittalrishabh]

Let me know if you agree with 10 second initial back off

[lance6716]

just noticed that SplitAndScatterRegionByRanges has a maximum 4 seconds sleep for 8 times, so I think here we sleep 10 seconds is good.

[mittalrishabh]

I need lgtm label to checkin

[lance6716]

PTAL @D3Hunter

[ti-chi-bot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: D3Hunter, lance6716

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• br/pkg/lightning/OWNERS [D3Hunter,lance6716]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[ti-chi-bot]

[LGTM Timeline notifier]

Timeline:

• 2024-01-05 02:20:23.331794411 +0000 UTC m=+2396314.369021322: ☑️ agreed by lance6716.
• 2024-01-08 04:08:25.378208741 +0000 UTC m=+243494.962462429: ☑️ agreed by D3Hunter.

[ti-chi-bot]

@mittalrishabh: The following test failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name	Commit	Details	Required	Rerun command
idc-jenkins-ci-tidb/check_dev_2	dd863e2	link	unknown	/test check-dev2

Full PR test history. Your PR dashboard.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

[lance6716]

/retest

[ti-chi-bot]

In response to a cherrypick label: new pull request created to branch release-6.5: #50164.

[ti-chi-bot]

In response to a cherrypick label: new pull request created to branch release-7.5: #51929.

[ti-chi-bot]

In response to a cherrypick label: new pull request created to branch release-7.1: #56874.