Vertically shard tables into existing keyspace

[tirsen]

We're not sure if we're going to need this feature but it would be interesting to explore how much work it would be to support it.

We're preparing to do a vertical split of our major database and we're having some anxieties around which tables should go into the keyspace that is going to be sharded.

If we make the wrong decision and accidentally leave some tables behind could Vitess potentially support moving tables from a keyspace to an already existing keyspace?

It seems like it wouldnt be too hard to move tables into an unsharded keyspace. Could Vitess also support moving tables into a sharded keyspace? I.e. doing a split clone of a single table and then setting up a filtered replication relationship of a single table into multiple existing shards.

[alainjobart]

We've been asked about this a few times, it would be a nice feature to have. A couple comments:

• in all the resharding workflows we have (vertical splits, horizontal resharding - both split and merge), the destination shard is always empty before we switch to it. The main reason for this is we can turn off the QueryService before the switch, so we're sure no DML makes it there when it shouldn't. However, in this case, all we need is to blacklist the tables that are being migrated on the destination shard before we migrate them, to have the same guarantees (the same way we blacklist tables right after they've been migrated on the source shards). So this change can be made somewhat easily.

• as far as moving tables from an unsharded keyspace to a sharded keyspace, the first guarantee we'd need is that we know the keyspace_id (or can compute it) on the source shards, so it can be inserted in the statements, or computed from the rows if using RBR. Once that's established, filtered replication needs to be changed a bit to support both table list and keyspace_id filters at the same time (right now it does one or the other). Then we can set this up.

None of these changes are really hard, it's just a matter of coding the policies, and implementing an end-to-end test. Filtered replication itself is very easy to configure, supports multiple streams from any random source, and overall 'just works'. Migrating the 'served types' is also very easy: mark the source read-only, wait for filtered replication to catch up, move the topology records, mark the destination read-write.

[tirsen]

I'm glad to hear that this doesn't sound too hard if it's something we're going to need in the future.

[mattlord]

I'm going to close this as done via the MoveTables command: https://vitess.io/docs/concepts/move-tables/