statistic: solve write write conflicts of mysql.stats_histograms #23831
Conversation
|
[REVIEW NOTIFICATION] This pull request has not been approved. To complete the pull request process, please ask the reviewers in the list to review by filling The full list of commands accepted by this bot can be found here. Reviewer can indicate their review by writing |
ti-chi-bot
added
the
size/S
jianzhiyao
force-pushed
the
frt/write_conflict
branch
from
54bb1cd to
3163746
Compare
|
PTAL @djshow832 |
There was a problem hiding this comment.
I don't understand the purpose of this PR, or the intention of the issue. It is reasonable that conflicts happen since there may be several tidb servers dumping their stats delta simultaneously, and when conflicts happen, the stats delta is not cleared, so it can be retried for the next time. I don't believe this is a problem that we should fix.
| @@ -688,7 +688,7 @@ func (h *Handle) FlushStats() { | |||
| } | |||
| } | |||
| if err := h.DumpStatsDeltaToKV(DumpAll); err != nil { | |||
| logutil.BgLogger().Error("[stats] dump stats delta fail", zap.Error(err)) | |||
| logutil.BgLogger().Error("[stats] dump stats all fail", zap.Error(err)) | |||
There was a problem hiding this comment.
Why?
There call h.DumpStatsDeltaToKV(DumpAll) but log message is delta
Maybe that issue want to reduce write-write conflicts when updating stats delta? So I use pessimistic transaction in here. |
What problem does this PR solve?
Issue Number: close #21787
Problem Summary:
the internal SQL in the slow log should not be check write conflict
What is changed and how it works?
How it Works:
run query in pessimistic transaction.
Check List
Tests
Side effects
Release note