Renamed to MariaDBServer. The objects have a pointer to the underlying
MXS_MONITORED_SERVER. The purpose is to have the monitor mainly use
MariaDBServer instead of the current mix of MXS_MONITORED_SERVER* and
MySqlServerInfo and to simplify the mapping between the two. Also,
many methods can be moved to the MariaDBServer class later on.
Some functions have been converted from MXS_MONITORED_SERVER* to
MariaDBServer.
When a multi-statement query consisting completely of UPDATE statements is
received, the packets can be received in two separate buffers. To cope
with this situation, the state change into REPLY_STATE_RSET_COLDEF must
only be done if the buffer contains more than a single packet.
Exposing the canonicalization code in the luafilter allows it to be used
on the Lua side of things. This should enable some pretty cool stuff to be
done with it.
When a multi-statement query consisting completely of UPDATE statements is
received, the packets can be received in two separate buffers. To cope
with this situation, the state change into REPLY_STATE_RSET_COLDEF must
only be done if the buffer contains more than a single packet.
In theory, the value of m_master could change between reading it to
local variable and stopping monitor. To be on the safe side, stop the
monitor first.
The DCB pointer in the MySQLProtocol struct doesn't appear to be updated
in all cases which causes it to be an unreliable source. As the session
itself is always available and it always has the service pointer properly
set, it should be used instead.
Also removed the dead protocol compression code and replaced the
parameters with the service capability bits.
By making it conditional, we prevent the problems that arise when the
replication protocol is used in combination with the session state change
tracking. In addition to this, it prevents unnecessary work for routers
and filters that don't need it.
1. Move some remaining class data private.
2. Linebreak long lines.
3. Move current master autoselection inside class method.
4. Remove single-use constant #defines.
5. Monitor status is only written inside loop.
The database-level query now only takes rows with either a global
select privileges or non-null database privileges. The table-level
query only accepts non-null databases and no global privileges,
as users with global select are added by the previous section.
Now it is possible to control the soft and hard ttl of the
cache on a session basis. That is, it is possible to use
different TTLs for different SELECTs.
As the TTL is checked at lookup time, it need not be hardwired
when the storage instance is created. With this changed it is
possible to introduce @maxscale.cache.(soft|hard)_ttl user
variables using which a client can control what TTL should be
applied for a particular kind of data, which is requested by
MXS-1475.
In case the entry in the cache can not be used because the hard
TTL has kicked in, we fetch the data and update the cache
irrespected of the value if @maxscale.cache.populate. That way
an entry that once was put in the cache, will remain in the cache
(as long as there is space).
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.
