StartMonitor() now takes a MXS_MONITOR_INSTANCE and returns
true, if the monitor could be started and false otherwise.
So, the setup is such that in createInstance(), the instance
data is created and then using startMonitor() and stopMonitor()
the monitor is started/stopped. Finally in destroyInstance(),
the actual instance data is deleted.
The following type name changes
MXS_MONITOR_OBJECT -> MXS_MONITOR_API
MXS_SPECIFIC_MONITOR -> MXS_MONITOR_INSTANCE
Further, the 'handle' instance variable of what used to be
called MXS_MONITOR_OBJECT has been renamed to 'api'.
An example, what used to look like
mon->module->stopMonitor(mon->handle);
now looks like
mon->api->stopMonitor(mon->instance);
which makes it more obvious what is going on.
CreateInstance() (renamed from initMonitor()) and destroyInstance()
(renamed from finishMonitor()) have now tentatively been
implemented for all monitors.
Next step is to
1) change the prototype of startMonitor() to
bool (*startMonitor)(MXS_SPECIFIC_MONITOR*,
const MXS_MONITOR_PARAMETER*);
and assume that mon->handle will always contain the
instance,
2) not delete any data in stopMonitor(),
3) add monitorCreateAll() that calls createInstance() for all
monitors (and call that in main()), and
4) add monitorDestroyAll() that calls destroyInstance() for
all monitors (and call that in main()).
Now, all monitor functions but startMonitor takes a
MXS_SPECIFIC_MONITOR instead of MXS_MONITOR. That is, startMonitor
is now like a static factory member returning a new specific
monitor instance and the other functions are like member functions
of that instance.
Instead of using void there's now a MXS_SPECIFIC_MONITOR struct
from which monitor specific types can be derived. This change
does not bring about other benefits than a bit of clarity but
this is the first step in clearing up the monitor API.
Previously, if the list contained servers that were not monitored by
the monitor yet were valid servers, an error value would be returned
and the monitor failed to start.
With this update, the non-monitored servers are simply ignored when
forming the final list.
Also, added printing of the list to diagnostics.
The MariaDB Connector-C headers that are built by MaxScale must be
included before any system headers.
Fixed code that explicitly included the <mysql.h> header to use the
<maxscale/protocol/mysql.h> wrapper instead.
"servers_no_promotion" is a comma-separated list of servers
which cannot be chosen when selecting a new master during failover
(auto or manual), or when automatically selecting a new master
for switchover (currently disabled).
The servers in the list are redirected normally and can be promoted
by switchover when manually selecting a new master.
If the API versions do not match, MaxScale will treat this as an
error. The API versioning would allow backwards compatible changes but the
functionality to handle that is not implemented in MaxScale.
Updated API versions based on changes done to module APIs in 2.2.
Now detects some erroneous situations before starting switchover.
Switchover can be activated without specifying current master.
In this case, the cluster master server is selected.
All modules now have an 8-bit range for capability flags. Currently only
the client side authenticator and protocol capability bits are loaded due
to the fact that backend versions of these modules don't relate to a
particular service.
The state of the monitored servers is only persisted if the states of the
servers have changed. This removes the unnecessary disk IO caused by the
writing on the monitor journal.
Using timestamps to detect whether MaxScale was active or passive can
cause problems if multiple events happen at the same time. This can be
avoided by separating events into actively observed and passively observed
events. This clarifies the logic by removing the ambiguity of timestamps.
As the monitoring threads are separate from the worker threads, it is
prudent to use atomic operations to modify and read the state of the
MaxScale. This will impose an happens-before relation between MaxScale
being set into passive mode and events being classified as being passively
observed.
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 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.
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 failover command is simulated by executing a call to /usr/bin/echo
with all possible monitor parameters. This allows testing of the failover
mechanism without actually using the failover command.
The timestamp of the last change from passive to active is now
tracked. This, with the timestamps of the last master_down and master_up
events, allows detection of cases when MaxScale was failed over but the
failover was not done.
Currently, only a warning is logged if no new master has appeared within
90 seconds of a master_down event and MaxScale was set to active from
passive.
The last event and when the event was triggered is now shown for all
servers. The latest change from passive to active is also shown.
When an event occurs on a server, it is now stored so that the last event
for each server is known. This allows a state change to trigger an event
even if, at the time of the event, no action was taken.
This change is only cosmetic as no functionality is implemented.
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.
If a destroyed monitor is created again, it will be reused. This should
prevent excessive memory growth when the same monitor is created and
destroyed again.
The parameter names for monitors and servers now use a set of constant
names. This removes some of the errors caused by spelling mistakes when
the same parameter name is repeated in multiple places.
The service, filter and listener parameters should also be converted to
constants. This allows for a consistent user experience.
The relationships from servers to services and monitors and filters to
services were not implemented. Now each server lists the services and
monitors that use it and each filter lists the services that use the
filter.
This enables the creation of a server and linking of that server to
services and monitors in one atomic operation.
When a resource has a relation to another resource, it should be expressed
as a working link to the resource. By passing the hostname of the server
to the functions, we are able to generate working relation links.
The modules that implement a diagnostics entry point now return a JSON
type object. This removes the need to format data inside the modules.
The module implementations of these are not yet complete which means that
MaxScale will fail to compile.
Monitors can now be printed in JSON format. The REST API resource
`/monitors` accepts GET requests and returns a JSON representation of the
monitors as a response.
This number (defaults to 1) sets how many times mon_connect_to_db
will try to connect to a backend before returning an error. Every
connection attempt may take backend_connect_timeout seconds to
complete.
Also refactored code a bit. Renamed mon_connect_to_db to
mon_ping_or_connect_to_db, since it does not connect if the connection
is already alive.
