Whether all queries should be routed to the master after a multistatement
query is executed can now be controlled with the `strict_multi_stmt` option.
When the option is disabled queries executed after a multistatement query will
be routed normally.
This will prevent the routing of queries that modify data to the slaves.
In the future a more intricate solution can done where all the statements
are parsed and the destination is resolved based on the actual contents.
If transaction safety was disabled and a large event sent in multiple SQL
packets was received, the distribution of that event to the slaves would fail.
The empty packet sent after a large event which fits into exactly one packet
was written to disk and the writing of no bytes caused it to be treated as
an error.
The router->last_written is used to store the position where the last event was
written. The replication header is also stored in a separate structure in
the router which is used later when the last packet of a multi-packet event
arrives.
The checking of the master status and the possible error logging were done
in two different steps. This led to confusing error messages when the state
of the server changed between the check and the logging of the error message.
When a command that changes the session state is executed on all servers and
a slave server goes down, an error message was sent to the client even though
one wasn't expected. These appeared as odd connection errors on the client side.
When a query is being routed to the slave, it is not necessary to assert that
the master server's state is still master. It is possible that the master server
changes states while the query is being routed but that doesn't affect the query
being currently routed.
The master DCB was checked for NULL-ness but the proper way is to check if
the backend reference is closed. This will fix a debug assertion in addition
to possibly preventing crashes.
When the shard maps are being updated they are set into a stale state. This
means that one client connection is updating the shard maps and the information
in the shard map is not the most recent. This does mean that the information
is valid and authentication should succeed even if the shard map is stale.
The include directories previously used by MaxScale were from the embedded
library. All parts of MaxScale apart from the query classifier now use
the client libraries.
Now, qc_mysqlembedded is linked against MySQL's embedded library,
and MaxScale itself against Connector-C.
So, in order to build MaxScale, Connector-C must be installed.
This has been tested with Connector-C 2.2.1.
The build variable MYSQLCLIENT_LIBRARIES is no longer used.
The query_classifier library is now only a wrapper that loads an
actual query classifier implementation. Currently it is hardwired
to load qc_mysqlembedded, which implements the query classifier
API using MySQL embedded.
This will be changed, so that the library to load is specified
when qc_init() is called. That will then allow the query classifier
to be specified in the config file.
Currently there seems to be a conflict between the mysql_library_end()
call made in qc_mysqlembedded and the mysql_library_end() call made in
gateway.c. The reason is that they both finalize a shared library.
For the time being mysql_library_end() is not called in gateway.c.
This problem is likely to go away by switching from the client
library to the connector-c library.
When a slave server fails to execute a session command, the log message printed
the command that was being executed as if the ERR packet was a COM_QUERY packet.
This caused corrupt strings to be printed into the error logs.
In blr_slave_callback the bits of slave->cstate are reset and
set as one transaction. Earlier they were reset in one and
set in another, leading to a situation where slave->cstate did
not contain a sensible value for a short period of time.
Further, it is now explicitly checked in blr_distribute_binlog_record
that slave->cstate indeed contains a meaningful value.
A debug assertion in the readwritesplit would always fail when the master DCB
was NULL. This was caused by the fact that the debug assertion assumes that the
pointer that is passed to it is a valid pointer.
The master DCB was used without checking if it was still open. It was possible
that the master DCB was closed and processed before the client had fully
processed all queries which caused it to fail at a debug assertion.
The fix to this is to use the client's DCB to get access to the shared session
authentication data as it is protected by additional locks.
Only the query classifier needs the functionality of the embedded
server, while the rest of MaxScale is content with the client
library or Connector/C.
This have now been rearranged so that query-classifier links with
the embedded static library and then explicitly exports its own
functions using the query_classifier.map linker script. That way
query classifier will use the embedded library, while the rest of
maxscale use the client library, and this without conflicts.
Currently, query_classifier is not linked to maxscale-common,
but executables must link to maxscale-common and query_classifier.
This is the first change in an attempt to arrange the linking so that
more errors are detected at link-time.
- All files in server/core but for gateway.c are linked to one shared
library called maxscale-common.
- The files log_manager/log_manager.cc and utils/skygw_utils.cc are
built into maxscale-common as well.
- MaxScale itself consists now only of gateway.c and is linked with
maxscale-common.
- All plugins link with maxscale-common.
- All executables link in addition with {EMBEDDED_LIB}.
After this change, the change (MXS-517) where query_classifier is the
only component that uses ${EMBEDDED_LIB} and the rest mysqlclient can
be made much cleaner.
After a few additional steps, all shared libraries can be linked with
the linker flags "-Wl,-z,defs", which directs the linker to resolve
all symbols. That will require that all shared libraries list all the
libraries they need, but will at the same time ensure that any
missing symbols are detected at link-time and not at run-time.
