When the SERVER_BEING_DRAINED bit is on, if the number of connections
to the server is 0, the state is reported as "Drained", otherwise as
"Being Drained".
Since the current node id can be obtained using the function gtmnid()
the queries for finding out whether a node is in the quorum and whether
it is softfailed can be made simpler.
When a softfailed node is finally revoked, it will appear as the
single node in a functioning Clustrix cluster. To ensure that the
Clustrix monitor will not stick to that node, if the node that is
used as hub is softfailed, it is immediately replaced with another
node.
The config parameter ordering depends on which end of the linked list the
parameters are added. The test should be re-enabled once parameter handling
has been refactored.
Added a new module parameter type to be used for parameters
that specify a duration. With the suffixes 'h', 'm', 's' and
'ms' the duration can be specified in hours, minutes, seconds
or milliseconds, respectively.
Irrespective of how the duration is specified, it is always
returned as milliseconds.
For backward compatibility, when a duration value is read it must
be specifed how a value *not* defined using a suffix should be
interpreted; as seconds or milliseconds.
value = param->get_duration(name, mxs::config::INTERPRET_AS_SECONDS);
Session log files are now regularly checked for existence. If the log file
does not exist (likely because it has been rotated), a new log file is created.
Worker::STOPPED -> MONITOR_STATE_STOPPED
Worker::POLLING -> MONITOR_STATE_RUNNING
Worker::PROCESSING -> MONITOR_STATE_RUNNING
By defining the monitor state from the worker state there is
no risk they will ever get out of sync. And there is one thing
less to maintain.
As m_servers is a member of Monitor, it is better if the closing
of the MYSQL connections is done there, so that derived classes
do not need to remember doing that.
When the servers of a service are defined by a monitor, then
at startup all servers of the monitor should be added to relevant
services. Likewise, when a server is added to or removed from a
monitor at runtime, those changes should affect services as well.
However, whether that should happen or not depends upon the monitor.
In the case of the Clustrix monitor this should not happen as it
adds and removes servers depending on the runtime state of the
Clustrix cluster.
If the servers of a service are defined by a monitor (the config
has 'cluster=SomeMonitor'), then the addition of a server to a
a monitor should lead to that server being added to the service.
The services whose servers are defined using a monitor, will
now be populated from the monitor.
Note, no consideration has yet been given to runtime changes.
