Skip to content

br: concurrently set tiflash replicas #63360

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.

Sign up for GitHub

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

Jump to bottom
Open
wants to merge 1 commit into
base: master
Choose a base branch
from
Open

br: concurrently set tiflash replicas #63360

wants to merge 1 commit into from
+24 −13

Conversation

Leavrth
Copy link
Contributor

@Leavrth Leavrth commented Sep 3, 2025 •
edited
Loading

What problem does this PR solve?

Issue Number: close #63177

Problem Summary:
Currently, BR set tiflash replica one by one without any concurrency.

What changed and how does it work?

optimize the speed of setting tiflash replica after log restore

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

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

Documentation

  • 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 ti-chi-bot
Copy link

ti-chi-bot bot commented Sep 3, 2025

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by:
Once this PR has been reviewed and has the lgtm label, please assign bornchanger for approval. For more information see the Code Review Process.
Please ensure that each of them provides their approval before proceeding.

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

Needs approval from an approver in each of these files:

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 ti-chi-bot bot added do-not-merge/needs-tests-checked release-note-none Denotes a PR that doesn't merit a release note. size/M Denotes a PR that changes 30-99 lines, ignoring generated files. and removed do-not-merge/needs-tests-checked labels Sep 3, 2025
@tiprow tiprow
Copy link

tiprow bot commented Sep 3, 2025

Hi @Leavrth. 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-sigs/prow repository.

@codecov Codecov
Copy link

codecov bot commented Sep 3, 2025 •
edited
Loading

Codecov Report

❌ Patch coverage is 75.00000% with 5 lines in your changes missing coverage. Please review.
✅ Project coverage is 74.0205%. Comparing base (bd2072e) to head (5ad000c).
⚠️ Report is 17 commits behind head on master.

Additional details and impacted files 
@@               Coverage Diff                @@
##             master     #63360        +/-   ##
================================================
+ Coverage   72.7782%   74.0205%   +1.2423%     
================================================
  Files          1832       1848        +16     
  Lines        495769     495842        +73     
================================================
+ Hits         360812     367025      +6213     
+ Misses       113016     106132      -6884     
- Partials      21941      22685       +744
Flag Coverage Δ
integration 43.7845% <75.0000%> (?)

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

Components Coverage Δ
dumpling 52.8700% <ø> (ø)
parser ∅ <ø> (∅)
br 62.1788% <75.0000%> (+15.6697%) ⬆️
🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
  • 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

@ti-chi-bot ti-chi-bot
Copy link

ti-chi-bot bot commented Sep 3, 2025

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

Test name Commit Details Required Rerun command
pull-build-next-gen 5ad000c link true /test pull-build-next-gen
idc-jenkins-ci-tidb/build 5ad000c link true /test build
idc-jenkins-ci-tidb/unit-test 5ad000c link true /test unit-test

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-sigs/prow repository. I understand the commands that are listed here.

lance6716
lance6716 reviewed Sep 4, 2025
View reviewed changes
br/pkg/restore/log_client/client.go
workerpool := tidbutil.NewWorkerPool(16, "repair ingest index")
eg, ectx := errgroup.WithContext(ctx)
for _, sql := range sqls {
resetSQL := sql
Copy link
Contributor

Choose a reason for hiding this comment

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

I remember in our go version, we can directly use sql in for-loop

https://go.dev/blog/loopvar-preview

br/pkg/restore/log_client/client.go
for _, sql := range sqls {
resetSQL := sql
workerpool.ApplyWithIDInErrorGroup(eg, func(id uint64) error {
resetSession := resetSessions[id%uint64(len(resetSessions))]
Copy link
Contributor

Choose a reason for hiding this comment

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

seems ID are already allocated to 1 to worker pool size. So we can use resetSessions[id - 1]

br/pkg/restore/log_client/client.go
workerpool.ApplyWithIDInErrorGroup(eg, func(id uint64) error {
resetSession := resetSessions[id%uint64(len(resetSessions))]
log.Info("reset tiflash replica", zap.String("sql", sql))
return resetSession.ExecuteInternal(ectx, resetSQL)
Copy link
Contributor

Choose a reason for hiding this comment

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

If one SQL fails, should we continue to execute rest of them?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@lance6716 lance6716 lance6716 left review comments

Assignees
No one assigned
Labels
release-note-none Denotes a PR that doesn't merit a release note. size/M Denotes a PR that changes 30-99 lines, ignoring generated files.
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.

optimize the speed of setting tiflash replica after log restore
2 participants
@Leavrth @lance6716