The documentation listed the rules as a comma separated list when they
were parsed as a whitespace separated list. The match specifiers were also
defined as optional when in fact they were mandatory.
MXS-848 (partially). The QLA-filter now has additional options
to control the printing.
1. "append"
This toggles append-mode, where the filter opens the log files in
update mode (if file already existed) and only adds text to the end.
2. "print_service"
This toggles writing the service name onto each row. Mostly useful
with the unified_file-setting.
3. "print_session"
This toggles writing the session number onto each row. Mostly useful
with the unified_file-setting.
Also, the filter now writes a header to the beginning of the file
when creating it.
The printing has been separated to its own helper-function, in case
more accurate control will be added in the future.
The maximum count and maximum size of the cache can now be
specified and a storage can declare what capabilities it has.
If a storage modile cannot enforce the maximum count or maximum
size limits, the storage is decorated with an LRU storage that
can.
Added a document that describes the module command system and added the
necessary information in the dbfwfilter documentation.
The release notes also point to the newly created document.
Since it's a cache, we do not need to retain the data from one
MaxScale invocation to the next. Consequently, we can turn off
write ahead logging completely if we simply wipe the RocksDB
database at each startup. In addition, the location of the
cache directory can now be specified explicitly, so it can be
placed, for instance, on a RAM disk.
If a master once had slaves and is in the stale status, it will not retain
this status after a restart. Without storing on-disk information, the
stale master status cannot be deduced by looking at the master
alone. Because of this, the user should be able to manually enable the
stale master status.
The listen() backlog is now set to INT_MAX which should guarantee that the
internal limit is always higher than the system limit. This means that the
length of the queue always follows /proc/sys/net/ipv4/tcp_max_syn_backlog.
With the advent of qc_get_field_info, columns can now be matched.
However, there is still some undeterminism caused by the table
information not containing contextual information (exactly where
is the table used).
Further, suppose table X contains the column A and table Y contains
the column B, then given a statement like
SELECT a, b from X, Z;
we cannot know whether a is in X or Z, or b in X or Z, without being
aware of the schema, which we currently are not.
Consequently, as long as MaxScale is not aware of the schema, some
heuristics must be applied. For instance, if exactly one table is
referred to, then we can assume that columns that are not explicitly
qualified are from that table.
The rule tests are currently rather rudimentary and need to be
expanded.
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.
