Currently the state change explanations are only added to mariadbmon. They
are less relevant for Galera clusters as they themselves explain why they
change their states but should still be added to make them easier to
analyze.
The event that isn't explained and is most often encountered is the loss
of a Slave status. Most often the loss of a Slave status happens because
either the IO thread or the SQL thread has stopped. Printing the states of
the threads as well as the latest error should hint at what caused the
outage.
The information can be added to the REST API in 2.5 where the monitors can
add extra information to the server JSON.
We will continue to look for "clustrix" as well so that MaxScale
will continue to work with older releases. Clustrix was replaced with
xpand in all symbols.
Intended to be used from fatal signal handlers. As the statement will
be returned only while classification is in process, if a statement
is returned, it is an indication that the crash was caused by the
classification.
If the protocol routes a COM_QUIT packet to the backend, it must not
generate a packet when it is shutting down. This could cause unexpected
write errors if the backend server managed to close the socket before the
write was done.
By deferring the closing of a DCB until the protocol tells that it's in a
stable state, we avoid closing the connection mid-authentication. This
makes sure that all connections have reached a stable state before they
are closed which in turn prevents the connections from counting towards
aborted connects (or failed authentications like it did with the old fix).
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 charset sent in the handshake is now done with the following
priorities:
* First Master server
* Last Slave server
* First Running server or Down server whose charset is known
The change is that server in the Down state to which we've successfully
connected to can also be used as the charset source. This, in addition
with an "empty" default charset, helps avoid the use of the default latin1
charset unless absolutely necessary.
The mon_ping_or_connect_to_db resets the MYSQL handle which caused the
loss of the error message. Returning a new enumeration value for
authentication errors solves this problem.
The backend didn't expect AuthSwitchRequest packets in response to the
handshake response packets. This is allowed by the protocol and appears to
happen with at least MySQL 8.0.
