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

Expand slave_selection_criteria documentation

Browse Source 
Added a section about how `slave_selection_criteria` and
`max_slave_connections` affect each other.
This commit is contained in:
Markus Mäkelä 2017-03-02 13:33:45 +02:00
parent e2869052bd
commit 075ca42482
1 changed files with 19 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

19
Documentation/Routers/ReadWriteSplit.md
View File

@ -81,6 +81,25 @@ The `LEAST_GLOBAL_CONNECTIONS` and `LEAST_ROUTER_CONNECTIONS` use the connection
`LEAST_BEHIND_MASTER` does not take server weights into account when choosing a server.
#### Interaction Between `slave_selection_criteria` and `max_slave_connections`
Depending on the value of `max_slave_connections`, the slave selection criteria
behave in different ways. Here are a few example cases of how the different
criteria work with different amounts of slave connections.
* With `slave_selection_criteria=LEAST_GLOBAL_CONNECTIONS` and `max_slave_connections=1`, each session picks
one slave and one master
* With `slave_selection_criteria=LEAST_CURRENT_OPERATIONS` and `max_slave_connections=100%`, each session
picks one master and as many slaves as possible
* With `slave_selection_criteria=LEAST_CURRENT_OPERATIONS` each read is load balanced based on how many
queries are active on a particular slave
* With `slave_selection_criteria=LEAST_GLOBAL_CONNECTIONS` each read is sent to the slave with the least
amount of connections
### `max_sescmd_history`
**`max_sescmd_history`** sets a limit on how many session commands each session can execute before the session command history is disabled. The default is an unlimited number of session commands.