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

MXS-962: Add nonpositive priority for Galera nodes

Browse Source 
If a Galera node has a nonpositive priority, the node will never be chosen
as the master. This gives the user more control over how the master is
chosen.
This commit is contained in:
Markus Makela 2016-11-01 23:16:25 +02:00
parent 8778e0c81e
commit f38b510d2b
2 changed files with 33 additions and 7 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

28
Documentation/Monitors/Galera-Monitor.md
View File

@ -64,7 +64,16 @@ use_priority=true
## Interaction with Server Priorities
If the `use_priority` option is set and a server is configured with the `priority=<int>` parameter, galeramon will use that as the basis on which the master node is chosen. This requires the `disable_master_role_setting` to be undefined or disabled. The server with the lowest value in `priority` will be chosen as the master node when a replacement Galera node is promoted to a master server inside MaxScale.
If the `use_priority` option is set and a server is configured with the
`priority=<int>` parameter, galeramon will use that as the basis on which the
master node is chosen. This requires the `disable_master_role_setting` to be
undefined or disabled. The server with the lowest positive value in _priority_
will be chosen as the master node when a replacement Galera node is promoted to
a master server inside MaxScale.
Nodes with a non-positive value (_priority_ <= 0) will never be chosen as the master. This allows
you to mark some servers as permanent slaves by assigning a non-positive value
into _priority_.
Here is an example with two servers.
@ -86,8 +95,21 @@ type=server
address=192.168.122.103
port=3306
priority=2
[node-4]
type=server
address=192.168.122.104
port=3306
priority=0
```
In this example `node-1` is always used as the master if available. If `node-1` is not available, then the next node with the highest priority rank is used. In this case it would be `node-3`. If both `node-1` and `node-3` were down, then `node-2` would be used. Nodes without priority are considered as having the lowest priority rank and will be used only if all nodes with priority ranks are not available.
In this example `node-1` is always used as the master if available. If `node-1`
is not available, then the next node with the highest priority rank is used. In
this case it would be `node-3`. If both `node-1` and `node-3` were down, then
`node-2` would be used. Because `node-4` has a value of 0 in _priority_, it will
never be the master. Nodes without priority are considered as having the lowest
priority rank and will be used only if all nodes with priority ranks are not
available.
With priority ranks you can control the order in which MaxScale chooses the master node. This will allow for a controlled failure and replacement of nodes.
With priority ranks you can control the order in which MaxScale chooses the
master node. This will allow for a controlled failure and replacement of nodes.

12
server/modules/monitor/galeramon/galeramon.c
View File

@ -681,11 +681,15 @@ static MONITOR_SERVERS *get_candidate_master(MONITOR* mon)
if (handle->use_priority && (value = serverGetParameter(moitor_servers->server, "priority")) != NULL)
{
currval = atoi(value);
if (currval < minval && currval > 0)
/** The server has a priority */
if ((currval = atoi(value)) > 0)
{
minval = currval;
candidate_master = moitor_servers;
/** The priority is valid */
if (currval < minval && currval > 0)
{
minval = currval;
candidate_master = moitor_servers;
}
}
}
else if (moitor_servers->server->node_id >= 0 &&