The creation of a monitor from JSON relied on the non-JSON version for the
addition of default parameters but it proceeded to check the validity of
the parameters before it. Whenever parameters are checked, the default
parameters should be present.
If the last server was removed, the parameter would be rejected due to it
being empty. To remove the parameter, the
MonitorManager::reconfigure_monitor should be used. Also fixed the
unnecessary serialization after a failure to remove server from a monitor
and the fact that some errors were logged instead of written to the caller
of the command.
If a server with zero weight was chosen as the only candidate, it was
possible that the starting minimum value was smaller than the server
score. This would mean that a candidate wouldn't be chosen if the score
was too high. To preven this, the values are capped to a value smaller
than the initial minimum score.
This way the state is encapsulated in the object and the required changes
are done in one place. This makes the code reusable across all functions
making it easier to implement better monitor alteration code.
Increasing counter sizes from int to long for averages.
Rename random functions to end with _co instead of _exclusive to
indicate range [close, open[, and to allow future suffixes oc, cc and oo.
When default parameters are loaded, the type and module name are
added. This helps object serialization and allows all the code to expect
that all the parameters needed to create an object are always present.
Adding the same task twice isn't allowed. The API of the housekeeper tasks
might have to be changed in a way that makes it possible for the caller to
know whether a task has been added.
By passing strings instead of const char pointers to the task control
functions, we can safely make copies of them knowing that the contents
won't disappear.
The cluster check can only be made after the monitor has been
started. If done when monitor is configured it will at startup
be done when services are not yet available and hence they will
not be populated with the dynamically discovered servers.
The last server wasn't removed as the set of relationships was empty. In
addition to this, changes to relationships via the relations endpoint
wasn't reflected by the monitor parameters.
If a monitor was created at runtime, it was missing some parameters that
were assumed to be always present. In addition to that, the parameters
weren't validated against the list of common and module parameters.
Since the monitors always reconstruct the server list, the new servers can
be stored as a parameter. To make this possible, the
server_relationship_to_parameter helper function is needed.
This commit fixes the MaxCtrl test suite failures but does not fix the
failures in the REST API test suite.
Reactivating monitors shouldn't be done as it's simpler to actually
destroy and create a new one. The performance of reactivation is
insignificant compared to the possible inconsistency problems it allows.
Storing all the runtime errors makes it possible to return all of them
them via the REST API. MaxAdmin will still only show the latest error but
MaxCtrl will now show all errors if more than one error occurs.
The connections to servers being drained should not be closed like they
should be for servers in maintenance mode. The change in functionality
between 2.3 and develop caused the connections to be discarded if the
server was in either maintenance or drain mode.
By using a std::vector to store the keys, the cost of key lookup goes down
in comparison with std::unordered_map. The downside is the increase in
memory use in certain situations but given the fact that the intended
purpose of worker-local data is to store global data, this is unlikely to
have observable negative side-effects. Depending on the implementations of
std::vector and std::unordered_map, the use of std::vector could even
result in a smaller memory footprint.
Added an overload to execute_concurrently that takes an std::function as a
parameter and added a const version of operator* for rworker_local. Also
removed the std::move of the return value in rworker_local::values as it
can prevent RVO from taking place.
Alterations to monitors are now done with all changes present in the first
call to configure. This fixes the case where two parameters depended on
each other and one would get configured before the other.
Uncrustify always forced insertion of tabs which led to mangled formatting
of the parameters. Placing each part on a separate line seems to work
better and produce a more readable output.
Some SQL clients may default to a different authentication plugin than
"mysql_native_password". Since this is the only one supported by MySQL-
authenticator, the client is instructed to swap its plugin.
Because runtime changes are performed one at a time, adding replication credentials
to a mariadbmon which didn't have any would cause an error to be printed, and
the monitor would not start.
This is now fixed by allowing replication_user without replication_password. This
is not an ideal solution as a configuration file with only replication_user would be
accepted. Also, when adding the credentials to a monitor, replication_user must be
given first to avoid the error.
