As the router is the only one that knows what backends a particular
statement has been sent to, it is the responsibility of the router
to keep the session bookkeeping up to date. If it doesn't we will
know what statements a session has received (provided at least some
component in the routing chain has RCAP_TYPE_STMT_INPUT capability),
but not how long their processing took. Currently only readwritesplit
does that.
All queries are stored and not just COM_QUERY as that makes the
overall bookkeeping simpler; at clientReply() time we do not need to
know whether or not to bookkeep information, we can just do it.
When session information is queried for, we report as much information
we have available.
The causal_reads_timeout default value is too long when considering the
behavioral changes that MXS-2141 introduced. With a 10 second default
value, a result is returned to the client in a reasonable amount of time.
With causal_reads enabled, the query would return with an error if the
slave was not able to catch up to the master fast enough. By automatically
retrying the query on the master, we're guaranteed that a valid result is
always returned to the client.
The NULL values were not stored as NULL Avro values due to the fact that
the file format has no native NULL-ness for the basic types. To solve
this, all values must be stored as a union that contains the actual type
as well as the null type.
Unions were not implemented in the maxavro library but implementing means
simply recursing one level down.
If the query statement is wrongly treated as a table creation statement it
could cause a crash. To handle this, unknown SQL is now reported and the
processing is stopped early. This does not solve the root cause of the
problem but makes it possible to detect it in the future.
The admin files are now created with 640 permissions and automatically
created directories now properly set the permissions for the group as
well. All files and directories created by avrorouter and binlogrouter
also now correctly limit the read and write permissions only to the owner
and the group.
When a connection to a server is lost and the session command history is
disabled, the session will continue as long as at least one connection is
open. Previously the open connection calculation used the same code that
was used when a new session was created which only inspected the
configured server count instead of the actual open connection count.
Drop the requirement that GTID based replication is used for
the BinLog Galera "failover" mechanism. There is no reason for
that restriction; it works just as well with file+position based
replication.
The table creation was not detected as the function used to extract the
table name did not return the fully qualified names. Even if it did return
a fully qualified name, it wouldn't have been correctly processed.
When a read-only transaction fails due to a connection error, no message
would be logged. Also added an info level message for the case when a
backend connection would get closed before the session is in the correct
state and a debug assertion that the router session should never be closed
when the handleError method is called.
The binlogrouter uses buffers across worker threads which is no longer OK
in 2.3. The correct solution would be to store data in something other
than a GWBUF (e.g. std::vector) and protect the sharing with a mutex. The
current solution simply works around the assertions by using macros
instead of functions.
By biasing the values of all counter type scores to positive integers, the
server weights are always taken into use.
This fixes the case when weights were ignored until all score base values
were larger than zero (the mxs922_server test).
If the DCB is closed in handleError, it would be NULL in closeSession. To
only close the DCB in one place, the handleError can be reduced to writing
an error to the client and marking the failure as a fatal one.
The check for a closed session should never be needed as the core
correctly orders the calls to the module functions. The version numbering
was also not used.
Fixed the incrementation of the query counter so that it uses relaxed
atomic operations.
Replaced SPINLOCK with std::mutex where possible, leaving out the more
complex cases. The big offenders remaining are the binlogrouter and the
gateway.cc OpenSSL locks.
Removed the almost equal comparison and subsequent selection based on historical number of connections.
The effect of it was this: Select the server that has historically, weights or not, been slower. Tested this with 2.2
with maxscale on one server and mariadb:s on two servers with different network lags. The tests with historical
selects were clearly slower.
The debug assertion is wrong as the code was changed to prioritize hints
over the router target selection. Also removed the superficial check for
master, slave and relay master states as they are implied by the fact that
the connection is in use.
The readwritesplit transaction management was a large part of the
clientReply function. Moving it into a separate function clarifies the
clientReply function by hiding the comments and details of the transaction
management.
The schemarouter now uses the RWBackend to track the response states. This
fixes the debug assertions that happened with the mxs1113_schemarouter_ps
test.
By splitting the processing and state querying into two separate
functions, the result can be inspected multiple times without triggering
the result processing.
This column will be used to store the relative path of the file
where a particular event can be found.
Unless the path is stored, BLR will not be able to find an event based
on the gtid if BRL is connected to a node in a Galera cluster and updates
are made to nodes other than that node as in that case, the GTID domain id
and server id, will not identify the correct directory.
The full path is not stored in the column binlog_file as the path
would in that case (without other modifications) be visible to the
client.
The collection of resultsets needs to be disabled by default when a
response is received to cover the cases where an error is returned.
The collection of results should also not be set for queries that do not
generate any responses.
