Add missing listener JSON diagnostics call. Check that the
diagnostics_json function exists before calling it.
As the protocol modules don't have diagnostics functions, they aren't
called.
Replace hard-coded strings with constant parameters. This makes it
slightly cleaner.
In some cases you might want to use a specific address/interface
when connecting to a server instead of the default one. With the
global parameter 'local_address' it can now be specified which
address to use.
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.
With this variables set to true, if $VAR is used as a value in the
configuration file, then `$VAR` will be replaced with the value of
the environment variable VAR.
The total timeout for the retrying of interrupted queries can now be
configured with the `query_retry_timeout` parameter. It controls the total
timeout in seconds that the query can take.
The actual connection, read and write timeouts of the connector aren't a
good configuration value to use for abstracted queries as the time that it
takes to execute a query can be composed of both connections, reads and
writes. This is caused by the usage of MYSQL_OPT_RECONNECT that hides the
fact that the connector reconnects to the server when a query is
attempted.
The new `query_retries` parameter controls how many times an interrupted
query is retried. This retrying of interrupted queries will reduce the
rate of false positives that MaxScale monitors detect.
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.
When a PATCH request to a resource is made with no relationships defined,
it should be interpreted to be the same as the old relationships. Removal
of relationships can still be done by defining an empty relationships
object.
All resoures now use the `state` member to describe their internal
state. This includes servers, services and monitors. This means that the
`status` keyword can be reserved for something else and it can be removed
until it is needed again.
Changed the module maturity field to `maturity` to better describe its
purpose.
The feedback system wasn't used and was starting to cause problems on
Debian 9 where the libcurl required different version of OpenSSL than what
MaxScale was linked against.
Several filters use a match-or-ignore logic with two regular
expressions when filtering queries. This commit adds a convenience
function for this task. Also adds a convenience function for reading
several regular expression parameters at once, compiling them and
saving the code while checking for errors.
Also, use the new functions in QLA and CCR filters.
The function now returns the compiled code or null or error. Also,
instead of capcount, it writes the ovector size. The ovector pointer
can be null. Removed the other config_get_compiled_regex()-function
and replaced it with the refactored function since they are almost
identical.
The module commands can now produce JSON formatted output which is passed
to the caller. The output should conform to the JSON API as closely as
possible.
Currently, the REST API wraps all JSON produced by module commands inside
a meta-object of the following type:
{
"meta": <output of module command>
}
This allows the output to be JSON API conformant without modifying the
modules and allows incremental updates to code.
The regex strings are compiled automatically. During file parsing,
the string is compiled once using default settings to check that
the pattern is valid. Once a module asks for the compiled pcre2_code,
the pattern is compiled again with module given settings.
The regex string in the config file should be enclosed within '/ ... /'
The module command self links now point to an endpoint that executes the
module command. Depending on the type of the module command, either a GET
or a POST request must be made.
The /users/ resource shows all user accounts that can be used with
MaxScale. This resource is further split into two resource collections,
/users/inet and /users/unix, which contain the network users and Linux
accounts respectively.
The REST API now uses the same users as MaxAdmin network interface. This
allows them to be created with MaxAdmin.
The next step is to add user creation to the REST API.
The requests that send a body should define at least a `data` member.
Added a simple test that checks that bad requests are rejected. This test
should be expanded to check that the returned error body contains the
correct members.
The /maxscale/ resource now has values for most of the configuration
parameters in the [maxscale] section as well as the version, commit and
uptime information.
The JSON objects that are created from the various core MaxScale objects
share a lot of common code. Moving this into a separate files removes the
redundant code.
The sessions resource now follows the JSON API specification:
http://jsonapi.org/
This makes the API relatively easier to use as the specification and the
client libraries to consume this data exist.
The service, filter and monitor resources now have a "parameters" value
which contains a set of all configuration parameters for that object. This
set contains both standard and non-standard parameters.
Also fixed a mistake in the constant name definitions for the monitor
parameters "events" and "script".
