-
Notifications
You must be signed in to change notification settings - Fork 131
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
Optimize the performance of bidirectional synchronous update table of _drainer_repl_mark #903
Conversation
…of _drainer_repl_mark
/run-all-tests |
1 similar comment
/run-all-tests |
/run-all-tests |
LGTM, @july2993 PTAL |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is there any test result
/run-all-tests |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
rest LGTM
var args []interface{} | ||
sql := fmt.Sprintf("update %s set %s=%s+1 where %s=? and %s=? limit 1;", loopbacksync.MarkTableName, loopbacksync.Val, loopbacksync.Val, loopbacksync.ID, loopbacksync.ChannelID) | ||
args = append(args, e.addIndex(), e.info.ChannelID) | ||
_, err1 := tx.autoRollbackExec(sql, args...) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
maybe we can check the affect rows to make sure we do update some row?
pkg/loader/executor.go
Outdated
for id := 0; id < e.workerCount; id++ { | ||
args = append(args, id, e.info.ChannelID, status, channel) | ||
} | ||
tx, err := e.begin() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
in e.begin() it will updateMark
it's confusing doing this.
suggest writing a func to accepte a *sql.DB
directly to initMarkTable
/run-all-tests |
cherry pick to release-3.0 in PR #909 |
What problem does this PR solve?
1.Optimize the performance of bidirectional synchronous update table of _drainer_repl_mark
What is changed and how it works?
The number of channel related records in the mark table is initialized according to the number of worker "count. During synchronization, each syncer operates one piece of data, which will not cause multithreading to update one record, resulting in synchronization performance bottleneck of mark table.
Check List
Tests
Code changes
Side effects
Related changes
tidb-ansible
repository