If shutdown has been initiated (via maxadmin or by sending a
SIGINT or SIGTERM) and a SIGTERM is received, the process
is terminated.
If shutdown has been initiated (via maxadmin or by sending a
SIGINT or SIGTERM) and a SIGINT (Ctrl-C) is received, a warning
is printed that shutdown is in progess. Then, if an additional
SIGINT is received, the process is terminated.
So, in practice:
- If MaxScale is running as a daemon, the first SIGTERM initiates
shutdown and a second one unconditionally terminates the process.
- If MaxScale is running in the console, the first Ctrl-C initiates
shutdown, the second prints a warning and the third terminates
the process.
This is to ensure that MaxScale can be forced to exit, in
case some thread is hung for whatever reason, and is thus preventing
the controlled shutdown.
The hangup code was refactored into a common function which should only be
used after the server states have been updated. This will remove erroneus
connections to already failed servers.
The master reference used by the readwritesplit sessions needs to be
reassigned if slave reconnection occurs. This happens because the
reference refers to a certain place in the backend reference array
instead of the actual backend reference and those places are mixed
when the array is sorted.
The qlafilter now has an option to log all messages to a single
file instead of session-specific files. Session ids are printed
to the beginning of the line when using this mode. Documentation
updated to match. Also, added an option to flush after every
write.
When persistent connections were used, it was possible that the injection
of COM_CHANGE_USER statements caused a crash when a DCB in the wrong state
was accessed.
For MySQL protocol modules, the `data` member of the client DCB points to
the shared session data, a MYSQL_session struct, but for sessions in the
persistent pool, it points to NULL. The boolean, `was_persistent`, tells
whether a DCB was just taken from the pool or it has been in use.
The `was_persistent` status wasn't properly reset for connections that
were put into the pool which caused a COM_CHANGE_USER statement to be
injected for stale connections in the pool which caused a crash when the
NULL `data` member was accessed.
The error logging is now more detailed and tells why the connection is
being closed. This should help the user figure out what is happening when
write fails and the connection is closed.
Some of the master server status checks didn't check whether the server
was actually running. The macros in server.h should always be used instead
of manually inspecting the server status.
If a readwritesplit session is active, it should never connect to a new
master. This will lead to unexpected results as the session states aren't
consistent.
If an illegal DCB close is done with a backend DCB, it will log the server
where it was connected. This allows us to know whether the DCB was
connected to a master or a slave.
Added more debug assertions to readwritesplit code. The DCBs should never
enter the DCB_STATE_DISCONNECTED.
Removed useless debug log messages. The messages usually just flood the
logs with no use to the developers.
The filter can detect SERVER_MORE_RESULTS_EXIST which means the server
is sending more result sets: example:
DROP PROCEDURE IF EXISTS multi;
DELIMITER $$
CREATE PROCEDURE multi() BEGIN
SELECT 1;
SELECT id FROM t2 limit 40;
set @a=4;
SELECT 2;
END$$
DELIMITER ;
MySQL> call multi()
A debug assertion failed due to a NULL buffer but a non-zero packet
length. This was caused by a missing reset of the packet length after
freeing the buffers.
If a Galera node has a nonpositive priority, the node will never be chosen
as the master. This gives the user more control over how the master is
chosen.
Some error messages were logged at INFO level and some had conditions that
prevent the logging. Removed these restrictions that an error situation is
always logged.
The luafilter didn't use a format string with dcb_printf which can lead to
unexpected results if the returned string contains printf special
characters.
If a master_failure_mode was set to error_on_write, a reconnection to the
old master would happen after the following events:
- Master server fails and the connection is closed
- The master server recovers
- A slave fails and the connection is closed
- A replacement for the slave is searched
If these events took place, the master would be taken back into use with
an inconsistent session state.
When a persistent connection is taken from the pool, the state is reset
with a COM_CHANGE_USER on the next write. This allows reuse of persistent
connections without having to worry about the state of the MySQL session.
Binlog server is already configured: if there is no pending transaction
a new binlog file is created after CHANGE MASTER.
If as START SLAVE is issued replication starts as usuale.
If maxscale is restarted the replication starts using the new created
file.
While configuring binlog server for the first time, master.ini not
existent, the specified MASTER_LOG_FILE is created in the $binlogdir.
If START SLAVE command is not issued the replication can start after
restarting maxscale as the binlog file exists.
When a COM_CHANGE_USER statement was executed, the new user credentials
were copied after the authentication message was sent. This caused the
COM_CHANGE_USER to always succeed the first time as it used the current
credentials. The user credentials would always lag behind by one.
When checksum is in use and there is an error in replication stream
master connection the blr_terminate_master_replication has no effect.
MXS-961: The checksum detection calls
blr_master_delayed_connect(router); and connection is scheduled again.
The fix will break the main loop as soon as the error indicator byte is
seen and no other computation will be done (such as checksum)
