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.
The manipulation functions are currently static so that the container can be initialized
if required. This will be fixed later.
The new functions are taken into use in monitor management.
Replaces uses of config_get_param() in modules either with contains()
or get_string(). The config_get_param() is moved to internal headers,
as it allows seeing inside a config setting.
The default ECMAScript syntax appears to be broken on CentOS 7 which
effectively prevents its use in most cases. A more reliable alternative
would be to use the bundled PCRE2 library but the basic POSIX regular
expressions seem to work.
The likely reason for a node being down is that some cluster level
modifications have been performed. Consequently a cluster check should
be triggered in that case.
The script generates the required .avsc files without requiring a direct
connection to the database. This makes it easier to generate schemas in
more secure installations where direct access and installing dependencies
might not be easy.
When checking the node info, also include information about wheter
a node is being SOFTFAILed. If it is, turn on the `Being Drained`
bit.
A node is SOFTFAILed with the intention of removing it, so better
not to create new connections to it as they later would be broken
when the node is actually taken down.
It is now possible to [un]softfail a Clustrix node via MaxScale
using a Clustrix monitor module command.
In case a node is successfully softfailed, the `Being Drained` bit
will automatically turned on. Similarly, if a node is successfully
unsoftfailed, the `Being Drained` bit will be cleared.
Since the settings are now protected fields, all related functions were
moved inside the monitor class. mon_ping_or_connect_to_db() is now a method
of MXS_MONITORED_SERVER. The connection settings class is defined inside the
server since that is the class actually using the settings.
