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

Update MariaDBMonitor documentation

Browse Source 
Updates troubleshooting section.
This commit is contained in:
Esa Korhonen
2018-12-04 17:53:10 +02:00
parent 7872474595
commit a6cacbec17
1 changed files with 27 additions and 12 deletions
Download Patch File Download Diff File Expand all files Collapse all files

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

@ -36,7 +36,9 @@ Table of Contents
* [servers_no_promotion](#servers_no_promotion) * [servers_no_promotion](#servers_no_promotion)
* [promotion_sql_file and demotion_sql_file](#promotion_sql_file-and-demotion_sql_file) * [promotion_sql_file and demotion_sql_file](#promotion_sql_file-and-demotion_sql_file)
* [handle_server_events](#handle_server_events) * [handle_server_events](#handle_server_events)
* [Troubleshooting](#troubleshooting) * [Troubleshooting](#troubleshooting)
* [Failover/switchover fails](#failoverswitchover-fails)
* [Slave detection shows external masters](#slave-detection-shows-external-masters)
* [Using the MariaDB Monitor With Binlogrouter](#using-the-mariadb-monitor-with-binlogrouter) * [Using the MariaDB Monitor With Binlogrouter](#using-the-mariadb-monitor-with-binlogrouter)
* [Example 1 - Monitor script](#example-1---monitor-script) * [Example 1 - Monitor script](#example-1---monitor-script)
@ -754,25 +756,38 @@ the monitor rejoins the server and disables the events. This should only be an
issue for events running more often than the monitor interval or events that run issue for events running more often than the monitor interval or events that run
immediately after the server has restarted. immediately after the server has restarted.
### Troubleshooting ## Troubleshooting
### Failover/switchover fails
Before performing failover or switchover, the MariaDB Monitor first checks that Before performing failover or switchover, the MariaDB Monitor first checks that
prerequisites are fulfilled, printing any found errors. This should catch and prerequisites are fulfilled, printing any found errors. This should catch and
explain most issues with failover or switchover not working. If the operations explain most issues with failover or switchover not working. If the operations
are attempted and still fail, then most likely one of the commands the monitor are attempted and still fail, then most likely one of the commands the monitor
issued to a server failed or timed out. To find out exactly what the queries issued to a server failed or timed out. The log should explain which query failed.
sent to the servers are, start MaxScale with `--debug=enable-statement-logging`. To print out all queries sent to the servers, start MaxScale with
This setting prints all queries sent to the backends by monitors and `--debug=enable-statement-logging`. This setting prints all queries sent to the
authenticators. backends by monitors and authenticators.
A typical reason for failure is that a command such as `STOP SLAVE` takes longer A typical reason for failure is that a command such as `STOP SLAVE` takes longer than the
than the `backend_read_timeout` of the monitor, causing the connection to break. `backend_read_timeout` of the monitor, causing the connection to break. As of 2.3, the
In this case , increasing the timeout settings of the monitor should help. monitor will retry most such queries if the failure was caused by a timeout. The retrying
Another settings to look at are `query_retries` and `query_retry_timeout`. These continues until the total time for a failover or switchover has been spent. If the log
are general MaxScale settings described in the shows warnings or errors about commands timing out, increasing the backend timeout
[Configuration guide](#../Getting-Started/Configuration-Guide.md). Setting settings of the monitor should help. Another settings to look at are `query_retries` and
`query_retry_timeout`. These are general MaxScale settings described in the
[Configuration guide](../Getting-Started/Configuration-Guide.md). Setting
`query_retries` to 2 is a reasonable first try. `query_retries` to 2 is a reasonable first try.
### Slave detection shows external masters
If a slave is shown in _maxadmin_ or _maxctrl_ as "Slave of External Server" instead of
"Slave", the reason is likely that the "Master_Host"-setting of the replication connection
does not match the MaxScale server definition. As of 2.3.2, the MariaDB Monitor by default
assumes that the slave connections (as shown by `SHOW ALL SLAVES STATUS`) use the exact
same "Master_Host" as used the MaxScale configuration file server definitions. This is
controlled by the setting [assume_unique_hostnames](#assume_unique_hostnames).
## Using the MariaDB Monitor With Binlogrouter ## Using the MariaDB Monitor With Binlogrouter
Since MaxScale 2.2 it's possible to detect a replication setup Since MaxScale 2.2 it's possible to detect a replication setup