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

Document slave_selection_criteria and weightby interaction

Browse Source 
Documented how the slave_selection_criteria and server weights work.
This commit is contained in:
Markus Mäkelä 2018-05-18 18:10:32 +03:00
parent b72a7a8926
commit bdde3c44d9
No known key found for this signature in database
GPG Key ID: 72D48FCE664F7B19
1 changed files with 24 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

24
Documentation/Routers/ReadWriteSplit.md
View File

@ -152,6 +152,30 @@ reported by the server itself.
`LEAST_BEHIND_MASTER` does not take server weights into account when choosing a
server.
#### Server Weights and `slave_selection_criteria`
The following formula is used to calculate a score for a server when the
`weightby` parameter is defined.
```
score = x / w
```
`x` is the absolute value of the chosen metric (queries, connections) and
`w` is the weight of the server. The value of `w` is the relative weight
of the server in relation to all the servers configured for the
service. The server with the highest score that fulfills all other
criteria is chosen as the target server.
Read the [configuration guide](../Getting-Started/Configuration-Guide.md#weightby)
for a more detailed example on how the weights are calculated.
For `LEAST_CURRENT_OPERATIONS`, the metric is number of active queries on
the candidate server, for `LEAST_GLOBAL_CONNECTIONS` and
`LEAST_ROUTER_CONNECTIONS` it is the number of open connections and for
`LEAST_BEHIND_MASTER` it is the number of seconds a server is behind the
master.
#### Interaction Between `slave_selection_criteria` and `max_slave_connections`
Depending on the value of `max_slave_connections`, the slave selection criteria