The current code assumes that the variable names are in lowercase. This
fixes the galera monitoring that was broken by commit
43068d20b43a34d5f3b4b4db0fcce701b3cd7cad. In addition, lowercase names
also helps when comparisons are done with std::string.
This correctly triggers the session command response processing to accept
results from other servers than the current master backend if the session
can continue. If the session cannot continue, it will be stopped
immediately.
Fixed leak in load_utils.cc and the cache filter. Also changed all
instances of json_object_set with json_object_set_new to make sure it's
only used when the references are to be stolen.
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 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 use of the server state is not transactional across multiple uses of
the function. This means that any assertions on the target state can fail
if the monitor updates the state between target selection and the
assertion.
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.
The Connector-C was changed to always return only the client's charset,
not the actual charset that the connection ends up using. To cope with
this, the code has to use SQL to join the default character set name to
the default collation for it which can be used to extract the numeric ID
of the charset.
The slave backend would be closed twice if it would both respond with a
different result and be closed due to a hangup before the master
responded.
Added a test case that reproduced the problem.
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.
The default database was not exposed in the warning that was logged when
authentication failed. The authentication uses the username, host and the
default database to find the user entry and the lack of the default
database made it hard to know for sure which user entry a client should've
matched against.
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 password values are now masked with asterisks. This tells whether a
password is set or not but it does not expose any information about the
password itself.
The errors that are ignored by readwritesplit are now stored as the
current close reason in the Backend. This allows the information about the
error to be retained and it can be used later in the error handler to
display the true reason why the connection was closed.
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 SQL for the second recursive CTE table can be optimized by adding a
where condition on the recursive part that rules out users that are not
roles. The functionality remains the same as only roles can be granted to
users.
The number of sessions wasn't always incremented but it was always
decremented. This happened primarily when authentication failed. By making
the management of the counters a part of the object lifecycle, this
problem goes away.
The client count was incremented before authentication was complete, and
should be decremented if it fails. Otherwise service connection limit can
be easily reached.
This allows the same verbose information to be logged in the cases where
it is of use. Mostly this information can be used to figure out why a
certain session was closed.
By doing the reconnection only when a new query arrives, we prevent the
excessive reconnecting that is done when a server's actual and monitored
states are in conflict.
Because of how the user-data was read, the same service name could be
found multiple times if the user-search query matched multiple rows. Now
the service names are read to a set, which ignores duplicates. The same
service may be attempted again if the authentication fails and user-data
is fetched again.
