hcq/MaxScale
hcq/MaxScale
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

MXS-2362 Document SchemaRouter table-sharding limitations

Browse Source
This commit is contained in:
Esa Korhonen 2019-03-07 13:33:03 +02:00
parent c8078c99e5
commit b4c5500fa1
1 changed files with 11 additions and 15 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

26
Documentation/Routers/SchemaRouter.md
View File

@ -139,24 +139,20 @@ refresh_interval=60
This functionality was introduced in 2.3.0.
If the same database exists on multiple servers, but the database contains
different tables in each server, the SchemaRouter is capable of
transparently routing queries to the right server, depending on which table
is being addressed.
If the same database exists on multiple servers, but the database contains different
tables in each server, SchemaRouter is capable of routing queries to the right server,
depending on which table is being addressed.
For instance, suppose the database `db` exists on servers _server1_ and
_server2_, but that the database on _server1_ contains the table `tbl1` and
on _server2_ contains the table `tbl2`.
In that case, the query
As an example, suppose the database `db` exists on servers _server1_ and _server2_, but
that the database on _server1_ contains the table `tbl1` and on _server2_ contains the
table `tbl2`. The query `SELECT * FROM db.tbl1` will be routed to _server1_ and the query
`SELECT * FROM db.tbl2` will be routed to _server2_. As in the example queries, the table
names must be qualified with the database names for table-level sharding to work.
Specifically, the query series below is not supported.
```
SELECT * FROM db.tbl1
USE db;
SELECT * FROM tbl1; // May be routed to an incorrect backend if using table sharding.
```
will be routed to _server1_ and the query
```
SELECT * FROM db.tbl2
```
will be routed to _server2_.
## Router Options