MonitorDestroy() (renamed to monitor_destroy()) will be used for
actually destroying the monitor instance, that is, execute
destroyInstance() on the loaded module instance and freeing the
the monitor instance.
TODO: monitor_deactivate() could do all the stuff which is currently
done to the monitor in config_runtime(), instead of just
turning off the flag.
The old hkheartbeat variable was changed to the mxs_clock() function that
simply wraps an atomic load of the variable. This allows it to be
correctly read by MaxScale as well as opening up the possibility of
converting the value load to a relaxed memory order read.
Renamed the header and associated macros. Removed inclusion of the
heartbeat header from the housekeeper header and added it to the files
that were missing it.
The internal header directory conflicted with in-source builds causing a
build failure. This is fixed by renaming the internal header directory to
something other than maxscale.
The renaming pointed out a few problems in a couple of source files that
appeared to include internal headers when the headers were in fact public
headers.
Fixed maxctrl in-source builds by making the copying of the sources
optional.
The error message was not 100% accurate about the value. In addition to
that, neither the value itself nor the monitor or parameter names were
printed in the error message.
Only used in conjunction with queued connections, which are not
enabled anyway. Once that comes on the table again, better to use
some standard data structures.
As the passive parameter is only used by the failover and the failover can
only be initiated by the monitor, there is no true need to synchronize the
reads and write of this parameter.
As all runtime changes are protected by the runtime lock, only partial
reads are of concern. For the supported platforms, this is not a practical
problem and it only confuses the reader when other variables are modified
without atomic operations.
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.
The JSON API specification states that all resources must support direct
modification of resource relationships by providing only the definition
for a particular relationship type to a /:type/:id/relationships/:type
endpoint.
The relevant part of the JSON API specification:
http://jsonapi.org/format/#crud-updating-to-many-relationships
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.
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.
The `passive` parameter can be given in the configuration file or on the
command line. It is displayed in the diagnostic output and changes to it
are persisted.
The variable itself does nothing.
The `script_timeout` and `journal_max_age` parameters weren't handled in
the monitor alteration code.
Also added missing documentation to maxadmin help output for
`alter monitor`.
Added missing SSL parameters to servers resource output as well as added
the processing of these parameters when servers are created. It is
preferable to define servers as either encrypter or plain and to prevent
the modification of this at runtime.
The users are now stored as an array of JSON objects. Legacy users are
automatically upgraded once they are loaded and a backup of the original
users file is created.
Removed the password parameter from the `remove user` maxadmin command as
well as all of the relevant functions. Requiring that an administrator
knows the password of the account to be deleted is not a sound requirement
now that, at least in theory, two types of accounts can be created.
Only the protocol, port and address of the listener were used to check if
a listener exists. The check should also use the name of the listener to
be sure that each name is unique.
Expanded tests to check that the creation of duplicate listeners is
detected. Did minor improvements to related test code.
By moving the repurposing of the servers under the global server lock, the
repurposing of a server and allocation of a new server behave in the same
way.
Also fixed the wrong error message on server creation failure referring to
invalid server relationships.
