RFC: support "clone" of tablets via vReplication

[timvaillancourt]

Description

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:

1. Tablespace corruption is backed-up/restored (if it exists)
2. Tablespace fragmention is backed-up/restored
3. 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):

1. Destination tablet is set non-serving and/or transitions to RESTORE/DRAINED tablet-type
2. VStream copy of all tables from X tablet to Y
3. VStream catch-up to "close" to the Primary
4. Tear-down of worflow + setup of CHANGE REPLICA TO (MySQL replication)
5. Transition back to serving state
6. 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)

1. A user that would like an empty tablet to contain the data from another
2. 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