Description

This PR adds a new experimental feature: keyspace level sidecar database names. For the why, please see the feature request.

In this PR the sidecar db name can only be set when the keyspace is first created via the CreateKeyspace vtctl client command using the new --sidecar-db-name command flag. From that point forward it is immutable (w/o modifying the topo directly outside of Vitess). If no value is specified for the keyspace then it will be set to the default of _vt when the keyspace is created, and as a fallback the default will also be set when the first tablet is started within the keyspace if for any reason it's not already set in the topo keyspace record.

The management of the sidecar database resides entirely within a vttablet. This allows each vttablet in a keyspace to manage its own sidecar database independently of all other keyspaces and processes in the cluster. This allows e.g. for most tablets within a Vitess cluster to use the default sidecar name of _vt while some can use a non-standard name of e.g. _vt_import or __virtual_vitess_cluster for whatever purposes as needed (in various cases the tablet's mysqld instance may be participating in two distinct vitess clusters or two distinct keyspaces). From outside of the vttablet, Vitess is able to assume that the standard name of _vt is being used (including external/3rd party tooling that e.g. may be doing things like vtctlclient ExecuteFetchAsDba) unless talking directly to a tablet's mysqld instance.

Note there are two exceptions to the above rule today — where another process does need to know the sidecar database name that a vttablet is using (by way of the keyspace it's in). Both are in vtgate and are due to the fact that today vtgate sends raw SQL queries to a vttablet through the normal user query hot path (tabletserver's QueryExecutor.Execute()) in the following cases:

1. OnlineDDL's show vitess_migrations implementation
2. VTGate's Schema Tracker implementation

The plan is to eliminate these two exceptions in the future by leveraging new vttablet RPCs that vtgate can then use instead of the current SQL interface. This way we have proper encapsulation and vtgate does not need to be aware of the implementation details (in this case the schema vttablet uses for the storage).

Related Issue(s)

• Fixes: Feature Request: Support Custom/Variable Sidecar (_vt) Database Name on Tablets #12304

Checklist

• "Backport to:" labels have been added if this change should be back-ported
• Tests were added or are not required
• Documentation: Document Experimental Custom Sidecar Support website#1402