MXS-2426 Document the change in cluster operation failure handling

This commit is contained in:
Esa Korhonen
2019-04-16 17:40:27 +03:00
parent f90863761e
commit 64a8288f66

View File

@ -332,6 +332,11 @@ 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.
If an automatic cluster operation such as auto-failover or auto-rejoin fails,
all cluster modifying operations are disabled for `failcount` monitor iterations,
after which the operation may be retried. Similar logic applies if the cluster is
unsuitable for such operations, e.g. replication is not using GTID.
### External master support
The monitor detects if a server in the cluster is replicating from an external
@ -365,11 +370,6 @@ a number of iterations given in `failcount`. Failover will not take place when
MaxScale is configured as a passive instance. For details on how MaxScale
behaves in passive mode, see the documentation on `failover_timeout` below.
If an attempt at failover fails or multiple master servers are detected, an
error is logged and automatic failover is disabled. If this happens, the cluster
must be fixed manually and the failover needs to be re-enabled via the REST API
or MaxAdmin.
The monitor user must have the SUPER and RELOAD privileges for failover to work.
#### `auto_rejoin`
@ -497,9 +497,6 @@ MaxAdmin. The commands are only performed when MaxScale is in active mode.
It is safe to perform switchover or failover even with `auto_failover` on, since
the automatic operation cannot happen simultaneously with the manual one.
If a switchover or failover fails, automatic failover is disabled. It can be
turned on manually via the REST API or MaxAdmin.
When switchover is iniated via the REST-API, the URL path is:
```
/v1/maxscale/mariadbmon/switchover?<monitor-instance>&<new-master>&<current-master>