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

MXS-3892: Document the change in behavior

Browse Source 
It is worth documenting this change as the amount of queries done by
MaxScale is likely to decrease by a significant amount. This change can
also have a negative effect on the worst-case delay of the database
mapping but this isn't really a practical problem.
This commit is contained in:
Markus Mäkelä 2021-12-24 07:34:39 +02:00
parent 56ea0db3e6
commit 5724338959
No known key found for this signature in database
GPG Key ID: 5CE746D557ACC499
1 changed files with 15 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

15
Documentation/Routers/SchemaRouter.md
View File

@ -51,6 +51,21 @@ db1.t2 |MyServer1 |
db2.t1 |MyServer2 |
```
### Database Mapping
The schemarouter maps each of the servers to know where each database and table
is located. As each user has access to a different set of tables and databases,
the result is unique to the username and the set of servers that the service
uses. These results are cached by the schemarouter. The lifetime of the cached
result is controlled by the `refresh_interval` parameter.
When a server needs to be mapped, the schemarouter will route a query to each of
the servers using the client's credentials. While this query is being executed,
all other sessions that would otherwise share the cached result will wait for
the update to complete. This waiting functionality was added in MaxScale 2.4.19,
older versions did not wait for existing updates to finish and would perform
parallel database mapping queries.
## Configuration
Here is an example configuration of the schemarouter: