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
If there are some tables that aren't specified in the vschema (This can be the case especially for unsharded keyspaces), then global routing doesn't work for them despite schema tracking running.
It would be nice if we could get the following scenario to work -
A user sets up 2 keyspaces, one of which is unsharded.
They create a table in the unsharded keyspace but don't add it to the Vschema.
If schema tracking is running, if the table created has a globally unique name, then we should support global routing on it.
Use Case(s)
Described ☝️
The text was updated successfully, but these errors were encountered:
Global routing rules originally wasn't meant to work for tables that aren't part of the vschema. We tried addressing this limitation in #16517, but we ran into an issue with MoveTables as described in #16517 (comment).
There is no easy way to resolve this issue, so we after internal discussion we concluded that we won't be able to support this feature request. For global routing to work for tables created in an unsharded keyspace, they should be added to the vschema. To do this, the vschema can be updated and applied by the vtctld, or a DDL statement like ALTER VSCHEMA ADD TABLE keyspace_name.table_name can be run from the vtgate.
Feature Description
If there are some tables that aren't specified in the vschema (This can be the case especially for unsharded keyspaces), then global routing doesn't work for them despite schema tracking running.
It would be nice if we could get the following scenario to work -
Use Case(s)
Described ☝️
The text was updated successfully, but these errors were encountered: