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 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.
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.
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.
The preparation and closing of prepared statements was sent to all servers
even though the execution was always sent to the master. With this change,
all queries which interact with prepared statements are only sent to the master.
The sending of statement preparations to all servers is a problem when a
statement which depends on a database or a table is created and the DDL
statement which created that table has not yet been replicated to the
slaves.
In addition to fixing the aforementioned problem, this change should also
reduce unnecessary network traffic to slaves and improve the overall
performance of the prepared statements.
The soname version numbers were missing from all the library targets
properties which caused ldconfig to warn about non-symlink libraries
being installed.
If individual servers had a weightby parameter value greater than INT_MAX * 1000
the integer used for calculation would overflow and the server would end up
having a negative weight. This would cause all connections to pile up on this
server.
The same overflow was possible for the sum of all the weightby parameter values
even if no single parameter exceeded the limit.
The earlier log file based approach for enabling and disabling
messages has now been completely replaced with the syslog priority
based approach.
Similarly as with log files before it is now possible to enable
and disable a log priority for a particular session, even though
it apparently has not been used much.
The local test-programs of the logging has got minimal attention
only to make them compile. They should get an overhaul as they did
not work before either.
The combination of only one slave being used and the slave_selection_criteria
being LEAST_CURRENT_OPERATIONS can possibly cause a connection pileup on one
slave server. This would skew the query distribution heavily towards the first
available slave even if multiple slave were being used.
Having the maximum number of slave servers to be equal to the total amount of
available slaves allows for a more even and responsive distribution of the
query traffic.
The log manager variables lm_enabled_log_files_bitmask, log_ses_count
and tls_log_info that earlier were declared separately in every
c-file are now declared in the log_manager.h header.
Prepared statements are sent to the master instead of all servers.
The planned functionality to store the types of the prepared statements was not implemented
and all executions of prepared statements are sent to the master. Because of this the preparations
should be all sent to the master server instead of sending them to all servers.
Before these changes when max_sescmd_history was used the session
was closed when the limit was exceeded. With this change, when the
limit is exceeded the recovery of slaves and the session command history
are both disabled. This will allow the sessions to continue while still
keeping the old functionality of limited salve replacement.
The disable_sescmd_history and disable_slave_recovery parameters were combined
so that disabling the session command history will also disable slave recovery.
This way no harm can be done with disable_sescmd_history.
routeQuery calls route_single_stmt, which requires the GWBUF to be
contiguous. Earlier it was made contiguous (if needed) in
route_single_stmt. However, since the process of making a GWBUF
contiguous causes the original buffer to be freed, this would lead
to a double free later in routeQuery that frees the passed buffer.
This is prevented now by making the buffer contiguous before calling
route_single_stmt.
In the end of execute_sescmd_in_backend the buffer was consumed
in case the protocol function failed. Or actually if it returned
something else but 1.
In the case of mysql_backend, the buffer is always freed when
authorizing and either consumed or placed on the dcb writequeue
when the data is written.
That is, it is never ok to consume the buffer in this function.
The end-result is likely to be an abort.