The default database was not extracted correctly as the length of the
user's name did not include the null terminator. Also the comparison for
database name length used the smaller than operator instead of the correct
larger than operator.
If a DCB is closed before a response to the handshake packet is received,
the DCB's session will point to the dummy session. In this case no error
should be written to the DCB.
This is a cherry-pick of commit f53e112bf49766f1cc55516c2d7ee571461d483f
from the 2.2 branch.
The service for a dummy session will be NULL. If authentication fails for
a dummy session, then no service level actions should be taken.
Only the binlogrouter can trigger authentication failure with a dummy
session as it creates connections before the service itself has started.
The readqueue should never be explicitly assigned and should only ever be
appended to. This guarantees that the packets are read and processed in
the correct order.
Also removed an unused function that deals with the readqueue
manipulation.
When packets were routed individually, the qualification for the
persistent pool was done before the current command was updated. In
addition to this, the previous commit doesn't seem like it can even build.
The statement tracking was given the same buffer multiple times when a
large packet was spread across multiple buffers when a router with
RCAP_TYPE_STMT_INPUT was present.
The command tracking packet processing is redundant for routers that
require RCAP_TYPE_STMT as the same processing is done later when the
buffer is split into packets and routed. By using the split packets, the
protocol module can simplify the command tracking by a great deal for most
routers.
When backend authentication failed due to errors other than wrong
credentials, the users were unconditionally reloaded. This caused a spike
of activity whenever authentication failed for other reasons.
Also fixed the test that checks for this to look for the correct error
message.
Sending an error to the client allows the connector to show more
information to the user when the DCB is closed due to a reason internal to
MaxScale.
The error message states that the connection was killed by MaxScale to
distinct it from the error sent by the server. The error number and SQL
state are still the same as both errors should be treated the same way.
This builds on commit 1287b0e595a5f99026f66df7eeaef091b8ffc774 and cleans
up the original code. This fixes a bug introduced in the aforementioned
commit and cleans up the code.
The authentication code assumed that the initial request only had
authentication related data. This is not true if the client library
predicts that the authentication will succeed and it sends a query right
after it sends the authentication data.
When a COM_CHANGE_USER was executed, it is possible that the server
responds with a AuthSwitchRequest packet instead of an OK packet. In this
case, the server sends a new scramble which must be used to create the 20
byte hash that is expected as the response.
The COM_CHANGE_USER that is sent as a part of the reset process for a
persistent connection did not expect a AuthSwitchRequest packet to be sent
as that implies that the server did not take the authentication fast
path. In this case, an error message needs to be logged stating that the
server requested a different authentication plugin than was expected.
The response handling logic did not always take the last packet for
inspection when a COM_CHANGE_USER was executed. The OK packet will always
be the last one since the COM_CHANGE_USER is the last command that was
sent.
When an unexpected response to a COM_CHANGE_USER is received, it is now
processes and discarded instead of treated as an error. This will allow
further analysis of the situation in addition to possibly solving some of
the problems that the persistent connections have.
Added extra info level logging to relevant parts of the code that deal
with the COM_CHANGE_USER reply processing. This information should allow
tracking of the response state for debugging purposes.
The response to the COM_CHANGE_USER should always be turned into a
contiguous buffer of complete packets. This guarantees that the code that
processes it functions properly.
As COM_QUIT would terminate the connection, there's no need to initiate
the session reset process. Also make sure all buffers are empty before
putting the DCB into the pool.
Added extra debug assertions for parts of the code that are related to the
COM_CHANGE_USER processing.
When a persistent connection is reused, a COM_CHANGE_USER command is
executed to reset the session state. If the reused connection was closed
before the response to the COM_CHANGE_USER was received and taken into use
by another connection, another COM_CHANGE_USER would be sent to, again,
reset the session state. Due to the fact that the first response is still
on its way, it will appear as if two responses are generated for a single
COM_CHANGE_USER.
The way to fix this is to avoid putting connections that haven't been
successfully reset into the connection pool.
When a session is being closed in a controlled manner, i.e. a COM_QUIT is
received from the client, it is possible to deduce from this fact that the
backend connections are very likely to be idle. This can be used as an
additional qualification that must be met by all connections before they
can be candidates for connection pooling.
This assumption will not hold with batched and asynchronous queries. In
this case it is possible that the COM_QUIT is received from the client
before even the first result from the backend is read. For this to work,
the protocol module would need to track the number and state of expected
responses.
If a connection has not been fully established (i.e. authentication has
been completed) then it should not be considered as a connection pool
candidate.
There's no need to use Python 3 for the script and using it introduces
problems due to the poor availability of MySQL Connector/Python for
Python3.
ENUM, SET and DECIMAL values should have a length of -1 as the length is
meaningless for these types.
The schema generator program needs to add the real_type and length fields
if the data types define them.
Also fixed a bug where the real_type and length fields were checked for
generated fields.
This reverts commit f3c83770903151a0a3b53593c3e05fa0af94cd5f. The
functionality was used implicitly by modules that declare the
RCAP_TYPE_CONTIGUOUS_OUTPUT capability.
The RCAP_TYPE_STMT_OUTPUT is not used in its previous form. It can be
altered to route only complete packets back to the client. This allows
routers to do safer parsing on the results.
When log messages are written with both address and port information, IPv6
addresses can cause confusion if the normal address:port formatting is
used. The RFC 3986 suggests that all IPv6 addresses are expressed as a
bracket enclosed address optionally followed by the port that is separate
from the address by a colon.
In practice, the "all interfaces" address and port number 3306 can be
written in IPv4 numbers-and-dots notation as 0.0.0.0:3306 and in IPv6
notation as [::]:3306. Using the latter format in log messages keeps the
output consistent with all types of addresses.
The details of the standard can be found at the following addresses:
https://www.ietf.org/rfc/rfc3986.txthttps://www.rfc-editor.org/std/std66.txt
Printing all output as raw bytes allows MaxScale to control the formatting
process. This also removes the need to convert the bytes to Python strings
and the need to parse the JSON.
The json_stringn function should be used instead of the json_string to
allow null characters as well as non-null terminated strings to be
embedded in the JSON values.
The CDC example Python programs now decode the data as UTF-8 instead of
ASCII.
Transaction boundaries can now be detected using regexes.
All else being equal, it gives a 10% performance improvement
compared to qc-based detection.
In a subsequent change, mysql_client.c will be modified to use
qc_get_trx_type_mask() instead of qc_get_type_mask().
Currently the use of regex matching is turned on using an
environment variable. That will change.
The client protocol module can resolve whether a password was used based
on the information the authenticators gather before authentication is
done. It uses the authentication token length as the basis on which it
makes the decision.
