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

MXS-3198 Update MariaDB Monitor documentation on 10.5 privileges

Browse Source 
In the end, only minor changes as SUPER covers most of the
requirements.
This commit is contained in:
Esa Korhonen
2020-10-06 14:03:29 +03:00
parent e15b276273
commit 3230d88d4c
1 changed files with 19 additions and 8 deletions
Download Patch File Download Diff File Expand all files Collapse all files

27
Documentation/Monitors/MariaDB-Monitor.md
View File

@ -81,8 +81,8 @@ From MaxScale 2.2.1 onwards, the module name is `mariadbmon` instead of
`mysqlmon`. The old name can still be used. `mysqlmon`. The old name can still be used.
The `user` requires privileges depending on which monitor features are used. The `user` requires privileges depending on which monitor features are used.
REPLICATION CLIENT allows the monitor to list slave (replication) connections, REPLICATION CLIENT (or REPLICATION SLAVE ADMIN for Server 10.5) allows the
and is always required. See monitor to list replication connections, and is always required. See
[Cluster manipulation operations](#cluster-manipulation-operations) for more [Cluster manipulation operations](#cluster-manipulation-operations) for more
information on required privileges. information on required privileges.
@ -247,7 +247,7 @@ maxctrl clear server server2 Maint
Starting with MaxScale 2.2.1, MariaDB Monitor supports replication cluster Starting with MaxScale 2.2.1, MariaDB Monitor supports replication cluster
modification. The operations implemented are: modification. The operations implemented are:
- _failover_, which replaces a failer master with a slave - _failover_, which replaces a failed master with a slave
- _switchover_, which swaps a running master with a slave - _switchover_, which swaps a running master with a slave
- _rejoin_, which directs servers to replicate from the master - _rejoin_, which directs servers to replicate from the master
- _reset-replication_ (added in MaxScale 2.3.0), which deletes binary logs and - _reset-replication_ (added in MaxScale 2.3.0), which deletes binary logs and
@ -259,16 +259,27 @@ implementation of the commands.
The cluster operations require that the monitor user (`user`) has the following The cluster operations require that the monitor user (`user`) has the following
privileges: privileges:
- SUPER, to modify slave connections and set globals such as *read\_only* - SUPER, to modify slave connections, set globals such as *read\_only* and kill
- REPLICATION CLIENT, to list slave connections connections from other super-users
- SELECT on mysql.user, to see which users have SUPER
- REPLICATION CLIENT (REPLICATION SLAVE ADMIN in MariaDB Server 10.5), to list
slave connections
- RELOAD, to flush binary logs - RELOAD, to flush binary logs
- PROCESS, to check if the *event\_scheduler* process is running - PROCESS, to check if the *event\_scheduler* process is running
- SHOW DATABASES and EVENT, to list and modify server events - SHOW DATABASES and EVENT, to list and modify server events
``` ```
MariaDB [(none)]> grant super, replication client, reload, process, show databases, GRANT super, replication client, reload, process, show databases, event on *.* to 'myuser'@'maxscalehost';
event on *.* to 'myuser'@'maxscalehost'; GRANT select on mysql.user to 'myuser'@'maxscalehost';
Query OK, 0 rows affected (0.00 sec) ```
The privilege system was changed in MariaDB Server 10.5. The effects of this on
the MaxScale monitor user are minor, as the SUPER-privilege contains many of the
required privileges and is still required to kill connections from other
super-users.
```
GRANT super, reload, process, show databases, event on *.* to 'myuser'@'maxscalehost';
GRANT select on mysql.user to 'myuser'@'maxscalehost';
``` ```
In addition, the monitor needs to know which username and password a In addition, the monitor needs to know which username and password a