Feature Request: Rails startup (information_schema) queries to work with @replica usage when some keyspaces have no replicas

[notfelineit]

Feature Description

The following scenario fails during a MoveTables workflow:

• We have a source keyspace and a target keyspace
• All tables are being copied to the target VTTablet
• Source keyspace has 1 primary VTTablet
• Target keyspace has 1 primary VTTablet, and 2 replica VTTablets
• MoveTables SwitchTraffic --tablet-types=replica has been done
• In Rails DB configuration, user has specified: target_keyspace_name@replica

When Rails starts up, it issues queries like:

SELECT column_name FROM information_schema.statistics WHERE index_name = 'PRIMARY' AND table_schema = database() AND table_name = 'table_name' ORDER BY seq_in_index 

This query is documented in test cases here.

But those queries fail with:

target: source_keyspace_name.-.replica: no healthy tablet available for 'keyspace:"source_keyspace_name" shard:"-" tablet_type:REPLICA'

Desired behavior
If we know:

• an import is occurring where all the tables on the source keyspace exist on the target keyspace
• the source keyspace has no replica tablets
• User has specified target_keyspace_name@replica

We could make sure that information_schema queries are routed to only the target keyspace replica. Or, something else to just "make it work", since user has specified target_keyspace_name specifically. They can reasonably expect only target keyspace replicas to be targeted.

Actual behavior
information_schema queries are still being routed to the source keyspace.

Use Case(s)

See above scenario.

Potentially relevant PRs

#6932