The earlier @maxscale.cache.enabled has now been replaced with
@maxscale.cache.populate and @maxscale.cache.use that provide
for more flexibility.
With the former it is possible to control in what circumstances
the cache is populated and with the latter one when it is used.
Together they can be used for having a completely client driven
caching.
With 'enabled' it can be specified whether the cache should initially
be enabled or disabled. Useful as it is now possible to enable/disable
the cache dynamically.
With the changes in this commit it is possible to add and remove
MaxScale specific user variables. A MaxScale specific user variable
is a user variable that is interpreted by MaxScale and that
potentially changes the behaviour of MaxScale.
MaxScale specific user variables are of the format "@maxscale.x.y"
where "@maxscale" is a mandatory prefix, x a scope identifying the
component that handles the variable and y the component specific
variable. So, a variable might be called e.g. "@maxscale.cache.enabled".
The scope "core" is reserved (although not enforced yet) to MaxScale
itself.
The idea is that although MaxScale catches these, they are passed
through to the server. The benefit of this is that we do not need to
detect e.g. "SELECT @maxscale.cache.enabled", but can let the result
be returned from the server.
The interpretation of a provided value is handled by the component that
adds the variable. In a subsequent commit, it will be possible for a
component to reject a value, which will then cause an error to be
returned to the client.
There are 3 new functions:
- session_add_variable() using which a variable is added,
- session_remove_variable() using which a variable is removed, and
- session_set_variable_value().
The two former ones are to be called by components, the last one by
the protocol that catches the "set @maxscale..." statements.
Given the value in a statement like "SET SQL_MODE=..." this parser
is capable of deducing whether SQL_MODE is set to DEFAULT or ORACLE
or something else.
SetParser is capable of returning the exact variable and value
of a "SET X=Y" statement, in the cases where X is of a specific
set of variables; currently "SQL_MODE" and "@MAXSCALE...".
The actual value of the SET statement also needs to be parsed in
the case of SQL_MODE, but it becomes unnecessary convoluted if that
information somehow should conditionally be expressable in a return
value.
So, the value will be parsed separately.
If two services referred to the same filter instance, it would
cause the filter to deleted twice at MaxScale shutdown with a
crash as the result.
Now when the services are deleted we just collect the unique
filter instances and then delete them after all services have
been deleted.
When the master changes mid-session, the temporary tables are inevitably
lost. This could be avoided by routing temporary table creation to all
servers.
Testing of routing behavior with master_failure_mode=error_on_write and
allow_master_changes=true. By sending an error instead of closing the
connection when the master fails, the connection can resume execution if a
new master becomes available.
Added test cases that verify that the functionality works as
expected. Also made Mariadb_nodes::change_master less verbose when one of
the nodes is down.
If the connection to the backend where a read-only transaction is being
performed fails, the Backend object should be closed for it. This fixes a
debug assertion in readwritesplit.cc:check_and_log_backend_state which
asserts that the failed connection must not be in use after the error
handling is done.
Also reordered the failing assertion and the accompanying error message so
that the error is logged first.
Added some helper functions into the MaxScale class and default parameters
into the connection creation functions. Also made the ip() function const
correct.
Made the document more concise and added links to the download page. Made
the user grants easier to copy-paste and explained that they are used in
the following tutorials. Updated the links to the new tutorials.
The read-write splitting routing tutorial is a combination of the two
different read-write splitting routing tutorials. As with the connection
routing tutorial, this should reduce the maintenance burden.
The connection routing tutorial is a combination of the two different
connection routing tutorials. This should reduce the maintenance burden by
a significant amount.
The tutorials combine the Galera and MariaDB monitor configuration as well
as the server configuration sections that were duplicated for all
tutorials. This should make the documentation easier to maintain.
