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 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.
If the client DCB of the session was passed into the function, it was
possible that the session pointer for it was already set to null. The
session pointer of an open DCB is never null but a client DCB's session
pointer can be null if accessed via the MXS_SESSION object.
By incrementing the counters when the session is created, we know that the
counter will always be decremented correctly. This does cause the listener
session to be counted as an actual session but this is already present in
the statistics calculations and is something we have to live with in 2.3
This change also makes it possible to overshoot the connection count
limitation as the session creation is delayed until authentication
fails. Both of these problems are fixed in 2.4.
This causes the connection failure to be counted as an authentication
failure instead of a connection error. The former never causes the host to
be blocked which effectively solves the problem for most cases. The only
case where this would not work is where the network buffer for a backend
DCB is full right after the connection is created.
The hangup and error handlers now have unique messages. Although the
behavior in the handlers is practically the same in both cases, the cause
of the error is not the same.
If a socket error is present, it is added to the error message. If an
error is present, it should clearly show the reason why the TCP socket was
closed.
The is_fake_event boolean helps distinguish fake events from real
ones. This makes figuring out the real source of hangup events easier.
The client count was incremented before authentication was complete, and
should be decremented if it fails. Otherwise service connection limit can
be easily reached.
If a query returned multiple resultsets and the connection was broken
between the resultsets, the backend would not know that parts of the
response were already sent. This is caused by the cyclic nature of the
state machine when multi-result responses are being processed.
To fix the problem, the result size is tracked to know how many bytes have
been sent to the client. This is a backport of the
MySQLProtocol::Result::size from 2.5(develop).
The backend DCBs do not have to send hangups in the close protocol API
method. If the conditions for the hangup were true, the session was
already stopping meaning that the client DCB was already closed.
If an error is generated while a COM_CHANGE_USER is being done, it would
always use the sequence number 1. To properly handle this case and send
the correct sequence number, the COM_CHANGE_USER progress needs to be
tracked at the session level.
The information needs to be shared between the backend and client
protocols as the final OK to the COM_CHANGE_USER, with the sequence number
3, is the one that the backend server returns. Only after this response
has been received and routed to the client can the COM_CHANGE_USER
processing stop.
As is explained in MDEV-19893:
Client reads from socket, gets the packet from 1. with seqno=0, which
it does not expect, since seqno is supposed to be incremented. Client
complains, throws tantrums and exceptions.
To cater for clients that do not expect out-of-bound messages
(i.e. server-initiated packets with seqno 0), all messages generated by
MaxScale should use at least sequence number 1.
Deep-copying prevents subsequent modifications done by the caller from
affecting the data that can be potentially stored in the write queue of
the backend's DCB.
