You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This RFC proposes support for seamlessly adding an empty tablet to a shard via a vReplication workflow, named something such as CloneTablet or maybe BootstrapTablet
Arguably, tablets can be "cloned" via binary-based backup/restores, and this may be faster, but binary backups have some drawbacks such as:
Tablespace corruption is backed-up/restored (if it exists)
Tablespace fragmention is backed-up/restored
Binary backups are storage engine (and architecture?) specific. ARM is becoming a thing + MyRocks should be a bigger thing (IMHO)
Assumptions
vReplication rebuilds tables "logically" (and serially?), so it should be assumed that this may be slower than restoring a binary backup
Approach
Conceptually this workflow would be similar to an all-tables MoveTables, but from a single source tablet to a single destination tablet, without any of the special traffic routing logic
A hand-wavy ordering of events would be (+/- whatever I forgot):
Destination tablet is set non-serving and/or transitions to RESTORE/DRAINED tablet-type
VStream copy of all tables from X tablet to Y
VStream catch-up to "close" to the Primary
Tear-down of worflow + setup of CHANGE REPLICA TO (MySQL replication)
Transition back to serving state
Done 🎉
This process assumes:
vttablet is alive + registered with the topo (we know a tablet alias)
MySQL has an empty datadir (responsibility of the user - Vitess should confirm)
An override would be useful in some situations (--force perhaps)
Alternative Approach
An alternate, non-vReplication approach might be to wrap the MySQL "Clone" plugin/feature, however this will require Vitess to rely heavily on an external, optional MySQL functionality
There may be benefits to this approach in terms of performance if clone is more efficient in some way, but it may be faster based on binary vs logical backups - a comparison might be worthwhile
Use Case(s)
A user that would like an empty tablet to contain the data from another
A user that would like an existing tablet to have new on-disk tablespaces, potential reasons:
Removing possible fragmentation or corruption
Switching storage engines
Typical method is annoying ALTER TABLE ... ENGINE=<new> on drained hosts running both engines 👎
Rewriting every table via vReplication should(?) achieve a similar result more simply,
Switching system architectures
The text was updated successfully, but these errors were encountered:
Description
This RFC proposes support for seamlessly adding an empty tablet to a shard via a vReplication workflow, named something such as
CloneTablet
or maybeBootstrapTablet
Arguably, tablets can be "cloned" via binary-based backup/restores, and this may be faster, but binary backups have some drawbacks such as:
Assumptions
vReplication rebuilds tables "logically" (and serially?), so it should be assumed that this may be slower than restoring a binary backup
Approach
Conceptually this workflow would be similar to an all-tables
MoveTables
, but from a single source tablet to a single destination tablet, without any of the special traffic routing logicA hand-wavy ordering of events would be (+/- whatever I forgot):
RESTORE
/DRAINED
tablet-typeCHANGE REPLICA TO
(MySQL replication)This process assumes:
vttablet
is alive + registered with the topo (we know a tablet alias)--force
perhaps)Alternative Approach
An alternate, non-vReplication approach might be to wrap the MySQL "Clone" plugin/feature, however this will require Vitess to rely heavily on an external, optional MySQL functionality
There may be benefits to this approach in terms of performance if clone is more efficient in some way, but it may be faster based on binary vs logical backups - a comparison might be worthwhile
Use Case(s)
ALTER TABLE ... ENGINE=<new>
on drained hosts running both engines 👎The text was updated successfully, but these errors were encountered: