Schema Routing Rules
The Vitess routing rules feature is a powerful mechanism for directing traffic to the right keyspaces, shards or tablet types. It fulfils the following use cases:
- Routing traffic during resharding: During resharding, you can specify rules that decide where to send reads and writes. For example,
you can move traffic from the source shard to the destination shards, but only for the
rdonly
orreplica
types. This gives you the option to try out the new shards and make sure they will work as intended before committing to move the rest of the traffic.
ApplyRoutingRules #
You can use the vtctlclient command to apply routing rules:
ApplyRoutingRules -- {--rules=<rules> || --rules_file=<rules_json_file>} [--cells=c1,c2,...] [--skip_rebuild] [--dry-run]
Syntax #
Resharding #
Routing rules can be specified using JSON format. Here's an example:
{"rules": [
{
"from_table": "t@rdonly",
"to_tables": ["target.t"]
}, {
"from_table": "target.t",
"to_tables": ["source.t"]
}, {
"from_table": "t",
"to_tables": ["source.t"]
}
]}
The above JSON specifies the following rules:
- If you sent a query accessing
t
for anrdonly
instance, then it would be sent to tablet
in thetarget
keyspace. - If you sent a query accessing
target.t
for anything other thanrdonly
, it would be sentt
in thesource
keyspace. - If you sent a query accessing
t
without any qualification, it would be sent tot
in thesource
keyspace.
These rules are an example of how they can be used to shift traffic for a table during a vertical resharding process.
In this case, the assumption is that we are moving t
from source
to target
, and so far, we've shifted traffic
for just the rdonly
tablet types.
By updating these rules, you can eventually move all traffic to target.t
The rules are applied only once. The resulting targets need to specify fully qualified table names.