Online DDL: report rows_copied for migration (initial support in gh-ost) #8255
Conversation
Signed-off-by: Shlomi Noach <2607934+shlomi-noach@users.noreply.github.com>
shlomi-noach
added
Type: Enhancement
| // we don't update the table value. | ||
| return nil | ||
| } | ||
| query, err := sqlparser.ParseAndBind(sqlUpdateMigrationRowsCopied, |
There was a problem hiding this comment.
My only concern is that this ParseAndBind could be optimized by only parsing the statement once and re-binding on each update, but I see the same pattern is used throughout the executor, so optimizing only for updateRowsCopied seems wrong. I'll revisit this down the road and refactor the whole file.
There was a problem hiding this comment.
This statement is expected to run once or twice a minute (when a migration is running). All over the Online DDL code, I don't try to optimize query performance. Do feel free to rewrite if you want to have uniform coding style through the code, but optimization-wise this is not an interesting place IMHO.
go/vt/vttablet/onlineddl/executor.go
Outdated
| @@ -2703,8 +2725,12 @@ func (e *Executor) OnSchemaMigrationStatus(ctx context.Context, uuidParam, statu | |||
| if eta, err := strconv.ParseInt(etaParam, 10, 64); err == nil { | |||
| etaSeconds = eta | |||
| } | |||
| var rowsCopied int64 = 0 | |||
There was a problem hiding this comment.
Weird that the linter is not complaining about this. I thought we had a lint for not zero-initializing variables that are already zero-initialized.
There was a problem hiding this comment.
Agreed, weird. I'll clean it nonetheless.
Signed-off-by: Shlomi Noach <2607934+shlomi-noach@users.noreply.github.com>
Description
This PR introduces a new column
rows_copiedin_vt.schema_migrationstable and in the output forSHOW VITESS_MIGRATIONS ...queries.rows_copiedis either an exact or close estimate of the number of rows copied from the original table into the ghost table during a migration.rows_copiedis the exact number of rows.rows_copiedvalue can be slightly below the actual number of rows copied, depending on the type of failure.The value gets populated in this PR by
gh-ostmigrations. Work on #8015 will make the value available inonline(vreplication) migrations, too.There's an
endtoendtest that verifies the behavior in a sharded cluster.Related Issue(s)
Checklist