The qlafilter now has an option to log all messages to a single
file instead of session-specific files. Session ids are printed
to the beginning of the line when using this mode. Documentation
updated to match. Also, added an option to flush after every
write.
The Resources document lists all currently known resources and will be converted
to a list of separate resource documents once the individual resource documents
are done. The Headers and Response Codes document contains a list of request and
response headers and the HTTP return codes. This is a work in progress and will
be expanded upon.
Added initial versions of the filter, monitor, session and user resource
documents. These provide information about various parts of MaxScale and
allow interaction.
All PATCH operations expect a JSON Patch type document in the request
body. Examples modified accordingly.
Add MaxScale resource document which describes the resources that give the
global configuration options and show statistics.
The resources that link to other resources provide values as a list of
relative links. This reduces the amount of sent data when the client
doesn't require all parts of the resource.
Since the updating is not yet implement, it should be stated that the update API
will most likely be modified at some point.
The module resource is similar to `maxadmin show modules` and the log
resource contains status information about logs. The log resource also has
an "action" resource at `/maxscale/logs/flush` which flushes logs to disk
and rotates them.
Added start and stop entry points for services and monitors. Also added
missing service parameters to the list of parameters that can be updated.
The documentation lists listeners as a sub-resource of the
service. This allows the listeners of a particular service to be queried.
If a Galera node has a nonpositive priority, the node will never be chosen
as the master. This gives the user more control over how the master is
chosen.
The release notes now mention that the caching is done by the
authenticators, not by the core. It also mentions that only MySQLAuth
implements this functionality.
Added notes to binlogrouter documentation about the changes to the loading
and storing of users.
Cleaned up MySQL-Authenticator document to make it a bit easier to read.
The MySQL authenticator now injects the service user into the list of
allowed users if loading of database users fails. This allows the removal
of common code in the binlogrouter and maxinfo modules.
The MySQLAuth authenticator can now store the cached credentials in a
custom location. This is intended for the binlogrouter, which currently
uses a different location for the user cache.
The MySQL authentication modules now have their own document in the
Authenticators directory. Right now this document only describes the
general details of the MySQL authentication and the new option.
The concept of 'allowed_references' was removed from the
documentation and the code. Now that COM_INIT_DB is tracked,
we will always know what the default database is and hence
we can create a cache key that distinguises between identical
queries targeting different default database (that is not
implemented yet in this change).
The rules for the cache is expressed using a JSON object.
There are two decisions to be made; when to store data to the
cache and when to use data from the cache. The latter is
obviously dependent on the former.
In this change, the 'store' handling is implemented; 'use'
handling will be in a subsequent change.
The mysqlmon simple failover mode allows it to direct write traffic to a
secondary node. This enables a very simple failover mode with MaxScale
when it is used in a two node master-slave setup.
The TARBALL variable controls if a special tar.gz package is built when
packages are generated. This package has a different directory structure
compared to the RPM/DEB packages.
If RPM/DEB packages are built, tar.gz packages are not built. This makes
RPM/DEB generation faster and allows tarballs to be built separately with
a proper directory structures.
When a query has been sent to a backend, the response is now
processed to the extent that the cache is capable of figuring
out how many rows are being returned, so that the cache setting
`max_resultset_rows` can be processed.
The code is now also written in such a manner that it should be
insensitive to how a package has been split up into a chain of
GWBUFs.
MaxScale shouldn't require the service and monitor user checks. It makes
sense to disable the checks to speed up the startup process when the user
knows that the permissions are OK.
MaxScale shouldn't require the service and monitor user checks. It makes
sense to disable the checks to speed up the startup process when the user
knows that the permissions are OK.
The `detect_stale_slave` functionality used to only work when MaxScale had
the knowledge that a master server has existed and that replication was
working at some point in time. This might be a "safe" way to do it in
regards to staleness of the data but in practice it is preferrable to
always allow slave to be used for reads.
This change adds the missing functionality to the monitor by assigning
slave status to all servers which are configured as replication slaves
when no master can be found.
The new member variable that was added to the SERVER should be removed in
2.1 where the server_info offers the same functionalty without "polluting"
the SERVER type.
The mysqlmon now supports proper detection of multi-master topologies by
building a directed graph out of the monitored server. If cycles are found from
this graph, they are assigned a master group ID. All servers with a positive
master group ID will receive the Master status unless they have `@@read_only`
enabled.
This new functionality can be enabled with the 'multimaster' boolean
parameter.
