If a limit on the replication lag is configured, servers with unmeasured
replication lag should not be used. The code in question did use them even
when a limit was set as the value used for undefined lag was -1 which
always measured lower than the limit.
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.
By logging the password hash when user authentication fails due to a
password mismatch, we can be certain what the client sent and what is the
currently stored value in MaxScale. This should not be on by default which
is why a new parameter is required.
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 code in 2.3 was changed to allow "empty" SSL definitions now that the
system CA is used. The code in 2.4 did not allow this which caused non-TLS
connections to be created when only ssl=true was defined.
The code relied on last_read for the idle time calculation which caused
the pings that were written to not reset the idle time. This increased the
chance of multiple COM_PING packets being sent to a backend before a reply
was received.
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.
This prevents empty or failed reads from updating the last_read flag which
in turn gives us the correct connection idle time when network errors
occur.
The code registered both client and backend callbacks for backend
DCBs. This caused the whole connection to hang if backend side throtting
was ever triggered.
The fix to the bug where peer certificates were validated but not required
caused the default behavior to change. The default should've changed at
the same time the fix was made.
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.
