The directory was created when the configuration was being processed and
it wasn't checked unless it was configured to a non-default value. With
the addition of the path validation, the directory must be created
earlier.
Responses generated by replayed session commands must not be treated as
actual responses to retained statements. In 2.5 this is not a problem as
it is done implicitly with the pre-assignment of the server that delivers
the session command response.
Doing the directory permission checks after all the values have been set
helps avoid problems with intermediate values that aren't valid. This
happens when --basedir generates invalid derived paths and the correct path
is provided as an argument right after it.
The path parameter is read from the configuration file only if it hasn't
been modified by a command line option. The case where an invalid command
line option is given but a valid configuration parameter would override it
is still treated as an error.
Also added a clarifying comment into set_dirs to make sure the handling
for the two path parameters is not moved inside set_runtime_dirs.
Fixed the testing scripts for the REST API and MaxCtrl now that the
directory permission checks are done correctly. Previously some paths seem
to have been ignored.
During switchover/failover, server events are altered. The ALTER
EVENT command automatically modifies the event charset and collation
to the values of the connetion running the query. This may cause
the event to become invalid.
Fixed this by changing connection charset and collation to the ones
in the event description just before altering it.
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.
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.
The values were stored in the parameters object which is used for
configuration parameters in other endpoints. The proper place for them is
inside the attributes object.
Unlike readwritesplit, schemarouter will process all responses from
backends as if they are expected. There are cases where errors are
generated that aren't sent as a response to a query. These queries must be
ignored and not routed to the client. Copying the code as-is from
readwritesplit isn't the cleanest solution but it avoids refactoring code
in a patch release.
The custom error number (2003) used by the backend protocol code was not
an actual error number that the server would send. The error code in
question was for an error that only the C connector returns:
CR_CONN_HOST_ERROR. Using ER_CONNECTION_KILLED as the error number better
conveys the fact that the connection was killed due to a reason not
related to any ongoing query.
By using a known error number that is correctly handled, we also avoid
writing errors to the client in the middle of a resultset or as the
initial response to a result. This explains why the problem described in
MXS-3267 happened in the first place: an unrelated connection was lost in
the middle of a resultset and the error was interpreted as the end of a
resultset. As a result of there being more data to be read, the unexpected
result state messages were logged.
This could happen if a session command triggers a master reconnection and
the connection fails while the history replay is ongoing. The code assumed
that history replay would only happen when a query was in the query queue.
This tells the user whether a session is using TLS or not. Currently, only
the client TLS cipher is shown in MaxCtrl as the backend ciphers require
additional formatting.
