Online DDL plan via Send; "singleton" migrations on tablets

[shlomi-noach]

Description

Two in one!

1. This PR introduces (WIP) "singleton migrations": a setting where you can't submit a new migration if any of the relevant shards still has any other pending migration (queued, ready, running`).

2. The use case resurfaced the question of the use of topo in Online DDL. And I'm using the particular use case to begin the refactor away from topo.

Elaborating on the refactor, first:

Online DDL is still the only mechanism that utilizes topo as a mean to communicate from VTGate or vtctl to vttablets. There's advantages to going through topo (decoupling, persisted "request" entry, auto-retries), but there's also disadvantages: too decoupled, non-idiomatic path, added constraint on vtctld availability.

With the recent introduction of migration queries, #7663 , #7656 , I see a nice path out of topo and into more fine-grained control over migrations.

The changes offered here provide 1-version backwards compatibility, and for now require opting-in.

How will the new online DDL plan/engine flow work?

For some DDL queries (where the user intentionally opted-in), we create a Send engine primitive, just as we would for direct DDLs. We decorate the DDL query with online DDL hints. For example, assuming our ddl_strategy is online, the query:

alter table corder engine innodb

is decorated as follows:

alter /*vt+ uuid="38ea1d8d_95da_11eb_b1fa_f875a4d24e90" context="vtctl:38be36cc-95da-11eb-b1fa-f875a4d24e90" strategy="online" options="" */ table corder engine innodb

and sent via Send. The tablet planner (TODO) will intercept the query and realize there's online DDL hints, and that's how it will know that the query should run via onlineddl.Executor rather than a direct commit on the backend database.

About singleton migrations

To be implemented; the refactor came first. The user will use -singleton strategy flag, e.g.:

set @@ddl_strategy='online -singleton';
alter table ... ;

or

$ vtctlclient ApplySchema -ddl_strategy="gh-ost -singleton" -sql "alter table ..." my_keyspace

The query will return with UUID if no other pending migration exists on relevant shards, and will atomically fail if there's at least one shard with a pending migration.

This is not implemented yet; I will implement this using a timeout-based mechanism, to avoid overly complex two-phase-commit logic. There may be some constraints on the user (e.g. if one migration is -singleton then all others must also be -singleton or else behavior is undefined).

Notes to the reviewer

There's many files affected here, but most are just affected by the initial refactor (e.g. change of function signature). The main changes right now are:

• go/vt/sqlparser: all CREATE, DROP, ALTER statements now support comment_opt.
  • Technically I only needed that for CREATE TABLE, DROP TABLE, ALTER TABLE, but yacc doesn't like it.
  • DDLStatement now has SetComments() function which allows the us to inject comments into a statement.
• go/vt/schema:
  • created DDLStrategySetting, which is a formal representation of the ddl_strategy value; some logic moved outside of online_ddl.go and into ddl_strategy.go. OnlineDDL instance now uses said DDLStrategySetting.
  • NewOnlineDDLs function: refactor parser.go logic into a more formal breakdown of a ddl statement
  • NewOnlineDDL function chooses whether to decorate the SQL query with /*vt+ ... */ hints
• go/vt/vtgate:
  • engine/online_ddl.go: OnlineDDL primitive now chooses whether to write OnlineDDL request to topo, or to submit directly to tablets via Send
  • TODO: apply the same in revert_migration.go

Most other changes (e.g. schemamanager) are just by-product of the introduction of DDLStrategySetting, and I'm happy to say the refactor formalized and I think simplified a bit, the logic in those places.

Related Issue(s)

• Tracking: Online DDL: tracking issue #6926

Checklist

• Should this PR be backported?
• Tests were added or are not required
• Documentation was added or is not required

Deployment Notes

Impacted Areas in Vitess

Components that this PR will affect:

• Query Serving
• VReplication
• Cluster Management
• Build/CI
• VTAdmin

[systay]

Looks good from what I can see. Mostly looked over parser, engine and both planners

[systay]

nit: 2021

[shlomi-noach]

fixed

[systay]

nit:2021

[shlomi-noach]

fixed

[systay]

instead of adding a comment that this is done later, why not just do it in here straight away? just to keep the logic easier to follow

[shlomi-noach]

I see what you mean, but there is code that is shard to all DropTable, CreateTable, AlterTable that is performed after the switch statement, when DropTable has, on top, special handling. I've clarified that in code comments.

[shlomi-noach]

Refactored. It does look better now

[systay]

nit:vterrors is your friend. this applies to quite a few errors in this file.

also, I believe errors should not start with a capitalised letter

[shlomi-noach]

Replaced all fmt.Errorf() in this file with vterrors, lower case as needed.