-
Notifications
You must be signed in to change notification settings - Fork 2.1k
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
Online DDL --analyze-table
: use non-local ANALYZE TABLE
#17462
base: main
Are you sure you want to change the base?
Conversation
Signed-off-by: Shlomi Noach <[email protected]>
Review ChecklistHello reviewers! 👋 Please follow this checklist when reviewing this Pull Request. General
Tests
Documentation
New flags
If a workflow is added or modified:
Backward compatibility
|
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #17462 +/- ##
==========================================
- Coverage 67.66% 67.65% -0.01%
==========================================
Files 1584 1584
Lines 254360 254362 +2
==========================================
- Hits 172116 172098 -18
- Misses 82244 82264 +20 ☔ View full report in Codecov by Sentry. |
@@ -208,7 +208,7 @@ func (v *VRepl) executeAnalyzeTable(ctx context.Context, conn *dbconnpool.DBConn | |||
defer conn.ExecuteFetch(sqlDisableFastAnalyzeTable, 1, false) | |||
} | |||
|
|||
parsed := sqlparser.BuildParsedQuery(sqlAnalyzeTable, tableName) | |||
parsed := sqlparser.BuildParsedQuery(sqlAnalyzeTableLocal, tableName) |
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.
OK, so this is only called as part of the analyze
step where it makes sense not to replicate it. Versus the cutover step where we continue (pre #7201) to use the replicated variant.
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.
Correct!
Description
Followup to #17201. In that PR we issue a
ANALYZE NO_WRITE_TO_BINLOG TABLE
on the shadow table just before cut-over, which brings statistics up-to-date and results in a more seamless transition as the shadow tabel takes the place of the original table.However, if a failover (PRS/ERS) takes place shortly after the cut-over, then the promoted replica's statistics for the shadow table can be far off. Or, irrespective of failover, read queries on replicas can also suffer from a sub-optimal execution plan.
With this PR we issue a "normal"
ANALYZE TABLE
which is then replicated. This can cause an increase in replication lag at cut-over time, but it is generally expected to be low, as the shadow table is not yet used by any production traffic, hence is not under any concurrency and does not suffer from locking issues.Related Issue(s)
ANALYZE
the shadow table before cut-over #17201ANALYZE
it before cut-over. #17200Checklist
Deployment Notes