Moved mon_process_failover() from monitor.cc to mysql_mon.cc. Renamed
some functions and variables related to previous failover functionality
to avoid confusion.
The get_server_info function takes the monitor handle and a database and
returns the corresponding MYSQL_SERVER_INFO struct. This hides a part of
the actual implementation of the info struct from the monitor code,
allowing future refactoring to be done. It also makes the code a bit more
readable.
The values in the MYSQL_SERVER_INFO struct can now be updated with the
update_slave_status function.
Also moved the number of configured and running slave configurations into
the info struct. This removes the need to pass output parameters.
The MYSQL_SERVER_INFO struct is updated first and then the server status
is updated. This allows the function to be called without it affecting the
server state.
The parameter handling for monitors can now be done in a consistent manner
by establishing a rule that the monitor owns the parameter object as long
as it is running. This will allow parameters to be added and removed
safely both from outside and inside monitors.
Currently this functionality is only used by mysqlmon to disable failover
after an attempt to perform a failover has failed.
If a switchover_script parameter is given, its value will be used as
the switchover script. Otherwise the default will be used. Currently
just echo.
The MySQL Monitor now introduces two script variables, CURRENT_MASTER
and NEW_MASTER, that contain information about the current and new
master respectively.
Switchover is performed only if switchover has been enabled and MaxScale
is *not* in passive mode.
To be able to do that, we need to get hold of the MXS_MONITORED_SERVER
corresponding to the SERVER specified as the new master.
So, instead of just return a boolean indicating whether the server was
found or not we return the MXS_MONITORED_SERVER pointer.
Switchover expects one or two servers as argument, one (the new
master) if there is no master and two (the new master, and the
current master) if there currently is a master.
The procedure is as follows:
- Stop monitor
- Check that provided arguments are reasonable.
- If there is no master currently, then only one argument is
accepted.
- If there is a master, then it must also be specified.
This is to prevent pathological cases where the situation has
changed after the admin has issued the switchover command.
- Check the failover mode and disable it.
- Perform the failover.
- If succeeded, enable failover if it was.
- If it failed, if failover was enabled, do not enable it and log
an alert. If failover was not enabled, just log an error.
Tentative documentation.
With the 'switchover' config variable the switchover functionality
can be enabled. If enabled a REST API endpoint will appear, using
which that switchover can be initiated.
Switchover can only be performed when MaxScale is in active mode
and failover will be disabled for the duration of the switchover.
Only if the switchover succeeds, will failover be enabled again.
Might be easier to expose that REST API always and only change
the behaviour when calling it, instead of making it appear and
re-appear.
The `failover` and `failover_timeout` parameters are now declared as a
part of the mysqlmon module. Changed the implementation of the failover
function so that the dependencies on the monitor struct can be removed or
moved into parameters.
Split the state change processing and failover handling into two separate
functions and added a call to the failover function into mysqlmon. This
prevents unintended behavior when failover is enabled for non-mysqlmon
monitors. The parameter itself still needs to be moved into mysqlmon.
Moved the failover documentation to the mysqlmon documentation as it is
specific to this monitor.
The monitor performs simple monitoring of a group replication cluster. It
expects no extra parameters in addition to the common monitor parameters
and will only set master and slave status bits on the servers. It is a
part of the experimental package as it is a very experimental module.
Further improvements would be to add the usage of the synced state.
If MaxScale Binlog Server is detected by MySQL monitor, then Server
status is ‘Relay Master, Running’ without ‘Slave’: this way Binlog
Server cannot be used by any statement routing.
Additionally SELECT for replication lag is skipped as well.
It is now possible to specify the thread stack size to be used,
when a new thread is created. This will subsequently be used
for allowing the stack size to be specified for worker threads.
All monitors now persist the state of the server in a monitor journal
file.
Moved the removal of stale journals into the core and removed them from
the monitor journal interface.
Enabling the option hinders the use of maintenance mode with the root
master node in most use-cases.
This behavior occurs due to the fact that the maintenance mode causes a
server to be treted as if it was down. The Galera monitor waits for the
cluster to reorganize before assigning a new master node. This is correct
(but very unexpected) behavior for single instance use-cases.
The multimaster node detection uses stacks to sort the node groups. The
size of this stack was always assumed to be positive but it was possible
that it dropped down to -1 causing a crash when the stack was accessed
with the index number.
The multimaster node detection uses stacks to sort the node groups. The
size of this stack was always assumed to be positive but it was possible
that it dropped down to -1 causing a crash when the stack was accessed
with the index number.
The function should actually be in include/maxscale/protocol/mysql.h
and the implementation in MySQLCommon, but the monitors do not link
to that yet.
All MySQL related should be moved to MySQLCommon and the core
refactored so that no MySQL knowledge is needed there.
Whenever a server which is a slave of an external master is detected, it
will be assigned the slave status. This will allow the status to be used
the way it was intended to be used.
The MySQL monitor replication_heartbeat table now uses the default storage
engine of the database when creating the table. Most of the time the
default is InnoDB which makes the table crash-safe.
If a monitor is started and stopped before the external monitoring thread
has had time to start, a deadlock will occur.
The first thing that the monitoring threads do is read the monitor handle
from the monitor object. This handle is given as the return value of
startMonitor and it is stored in the monitor object. As this can still be
NULL when the monitor thread starts, the threads use locks to prevent
this.
The correct way to prevent this is to pass the handle as the thread
parameter so that no locks are required.
