If a DCB is expecting a response from the server, it must not be placed
into the connection pool. This prevents the case where unexpected
responses would be delivered to DCBs taken out of the connection pool.
The shutdown signal handlers were installed before the workers were
initialized and weren't removed before the workers were deleted. This
would lead to a debug assertion and an eventual crash when a SIGTERM
signal was received outside of the expected scope.
The proper way to do this is to install the handlers only after the system
is up and running and to disable them as soon as the shutdown process
starts.
This mostly happened with the mxs621_unreadable_cnf test as it seemed to
receive a SIGTERM during the execution of the at-exit handlers.
For whatever reason, galera complains on startup about
wsrep_cluster_address missing even when mysql_install_db is run. By making
sure that we configure it before we initialize the database, the problems
seem to go away.
The documents themselves were removed by MXS-2944, so the links
should not be there. Their presence will also prevent the documents
from being removed in KB.
Problem was that 'handler' is a keyword. To make it work,
the keyword must be listed as one of those that turns into
an id where it cannot be used as a keyword.
In some cases the dbfwfilter is too strict and SQL that would not match a
rule is blocked due to it not being fully parsed. To allow a more lenient
mode of operation, the requirement for full parsing must be made
configurable.
When a fake handshake response is generated for a connection that hasn't
received the server's handshake, the client's SHA1 would be used with a
static scramble. This, in theory, would weaken the authentication to some
extend so to completely prevent this, a null password is used. This
removes any possibility of the password being exposed.
The endpoint reloads the database users. This can also be used in the
future to refresh encrypted credentials when they are no longer loaded
every time an encrypted password is used.