-
Notifications
You must be signed in to change notification settings - Fork 2.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Vertically shard tables into existing keyspace #3142
Comments
We've been asked about this a few times, it would be a nice feature to have. A couple comments:
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. |
I'm glad to hear that this doesn't sound too hard if it's something we're going to need in the future. |
…xisting vreplication rows copied to local counter if resuming from another tablet (vitessio#3143) * backport of 3142 * Adjust for v17 Signed-off-by: Matt Lord <[email protected]> --------- Signed-off-by: Matt Lord <[email protected]> Co-authored-by: Matt Lord <[email protected]>
I'm going to close this as done via the |
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.
The text was updated successfully, but these errors were encountered: