Feature Request: Support Custom/Variable Sidecar (_vt) Database Name on Tablets

[mattlord]

Feature Description

If you are moving tables between Vitess clusters, you have the Mount+Migrate commands to use for that today.

A major drawback to using Migrate however is that it offers no rollback/revert functionality. For this reason, being able to use the standard MoveTables command when doing intra cluster data migrations is very desirable.

Use Case(s)

Any time you're moving tables between Vitess clusters, e.g. going from an on-prem cluster to one that lives in an IaaS/SaaS/PaaS provider.

Any time you're allowing your users to migrate tables into a Vitess cluster that you manage, you may not know if your user is already using Vitess. If they are, then using the existing sidecar (_vt) database on that mysqld instance that you're importing from can cause serious problems.

[shlomi-noach]

@mattlord while I generally understand the need for a custom sidecarDB, I'm do not understand the need for it as described above. Can you please clarify how:

A major drawback to use Migrate however is that it offers no rollback/revert functionality. For this reason, being able to use the standard MoveTables command

is related to a custom sidecarDB ? I'm sure I'm missing some context.

[mattlord]

@mattlord while I generally understand the need for a custom sidecarDB, I'm do not understand the need for it as described above. Can you please clarify how:

A major drawback to using Migrate however is that it offers no rollback/revert functionality. For this reason, being able to use the standard MoveTables command

is related to a custom sidecarDB ? I'm sure I'm missing some context.

@shlomi-noach Mount+Migrate is only needed because MoveTables does not support intercluster migrations. When the external tablet on the target side can use a custom sidecar database, so as not to interfere with the source vitess cluster and its operations — as both clusters have a tablet that is using the same mysqld instance during this time — then Mount+Migrate (which has the major drawback of being one way) is no longer needed.

[shlomi-noach]

Got it! Thanks so much, that's an angle I didn't think of!

[arthurschreiber]

Is the idea here to put a (potentially second) vttablet instance up in front of the existing MySQL instance, with it's own sidecar database as to not interfere with any potentially existing sidecar database? And this vttablet is part of the target topology, and all traffic is supposed to go through that target toplogy's vtgate instances (just like during a regular MoveTables workflow)?

[mattlord]

Is the idea here to put a (potentially second) vttablet instance up in front of the existing MySQL instance, with it's own sidecar database as to not interfere with any potentially existing sidecar database? And this vttablet is part of the target topology, and all traffic is supposed to go through that target toplogy's vtgate instances (just like during a regular MoveTables workflow)?

Correct. That's the primary use case in mind, but the general ability to have a single mysqld participating in two distinct Vitess clusters can open up some other known and unknown use cases as well.