pingcap
Support resolve blocking of DMLs when one worker doesn't see all shard DDLs
Feature Request
Is your feature request related to a problem? Please describe:
The main processing logic of pessimistic sharding DDL is
- one DM-worker handles one upstream MySQL. When it reads a sharding DDL, it will block replicating DMLs of this shard and continue reading binlog, until all shards of this upstream MySQL have sent sharding DDL. At that time DM-worker will stop replicating, build a DDL lock and wait for DM-master to coordinate and resolve it
- DM-master waits for all DM-worker to build the DDL lock (if shards are splitted among N upstream sources, there should be N DM-worker to build the lock), let first DM-worker execute the DDL downstream and resolve all locks so DM-worker will continue to replicate binlog.
currently unlock-ddl-lock command is used to forcibly let DM-master resolve a lock. But when DM-worker doesn't see DDLs of all shard tables in its upstream, it didn't build a lock so there's no way to resolve blocking of shard tables whose sharding DDL has been seen.
Describe the feature you'd like:
Resolve above issue.
currently most related command is unlock-ddl-lock, but the parameter of this command is "lock ID" which is shown in show-ddl-locks. There's no "lock ID" when not see DDLs of all shard.
maybe we can propose a new command?
shard-ddl-lock
show ddl lock and partial synchronized sharding DDLs
shard-ddl-lock unlock <task> <-d target-database> <-t target-table> [--no-exec]
expect that the blocking of DML is resolved after this command
shard-ddl-lock inject <task> [-s source-id] <-d target-database> <-t target-table>
ignore unseen shard tables, build a DDL lock now
And I think for shard-ddl-lock unlock we can let DM-master to execute the DDL, to get rid of owner parameter of old unlock-ddl-lock.
Describe alternatives you've considered:
Teachability, Documentation, Adoption, Migration Strategy:
