Distributed table creation and drop for generic sharding. #5026
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Introduces syntax:
CREATE TABLE .... PARTITIONED BY TESTGENSHARD(dbname1, dbname2, dbname3, dbname4)
Dropping a partitioned table using the partition name drops the whole partition in one transaction.
Use a stub to interface with rest of sharding code, to provide shardnames, number of shards (hardcded 4), and location of databases. The only flexible parameter is for the database names used to store the shards. The stub code is marked to the best ability by the framing message: "THIS SECTION IS A STUB; TO BE REPLACED BY ACTUAL PARTITION SCHEMA". "END: THIS SECTION IS A STUB; TO BE REPLACED BY ACTUAL PARTITION SCHEMA".
In that sense, the code does not store anything in llmeta, and passes all configuration through SET and schema change options. It simplifies the partition by only using an table alias instead of a full-fledged view.
Testcase will create the partition, check it and remove it. [The row routing for read and writes is part of a separate PR, so no actual rows are read/written to the partition].