Documentation: add note on switchover command and log_slave_updates

This commit is contained in:
Esa Korhonen 2018-02-09 11:39:25 +02:00
parent e346968e0e
commit 2bd1d4ab88

View File

@ -246,14 +246,16 @@ In addition, the monitor needs to know which username and password a slave
should use when starting replication. These are given in `replication_user` and
`replication_password`.
All three operations can be activated manually through MaxAdmin. Failover
selects the new master server automatically, switchover and rejoin require the
user to designate the new master. Switchover also requires the user to designate
the current master server which will be replaced by the new. Example commands
are below:
All three operations can be activated manually through MaxAdmin/MaxCtrl. All
commands require the monitor instance name as first parameter. Failover selects
the new master server automatically and does not require additional parameters.
Switchover requires the new master server name. Additionally, the user may
designate the current master server in the switchover command. Rejoin requires
the name of the joining server. Example commands are below:
```
call command mariadbmon failover MyMonitor
call command mariadbmon switchover MyMonitor SlaveServ3
call command mariadbmon switchover MyMonitor SlaveServ3 MasterServ
call command mariadbmon rejoin MyMonitor NewServer2
```
@ -285,7 +287,7 @@ With `auto_rejoin` active, the monitor will try to rejoin any server matching
the above requirements. When activating rejoin manually, the user-designated
server must fulfill the same requirements.
### Limitations
### Limitations and requirements
Switchover and failover only understand simple topologies. They will not work if
the cluster has multiple masters, relay masters, or if the topology is circular.
@ -309,6 +311,13 @@ any users who commonly do updates should not have the SUPER-privilege. For even
more security, the only SUPER-user session during a switchover should be the
MaxScale monitor user.
When mixing rejoin with failover/switchover, the backends should have
*log_slave_updates* on. The rejoining server is likely lagging behind the rest
of the cluster. If the current cluster master does not have binary logs from the
moment the rejoining server lost connection, the rejoining server cannot
continue replication. This is an issue if the master has changed and
the new master does not have *log_slave_updates* on.
### Configuration parameters
#### `auto_failover`