By always restoring the ID, we are guaranteed to only store the query in
the form that it was originally sent in. This should be changed so that
the ID that the client sends can be used as-is in the backends.
By having a separate FINISHED state and a STOPPED state, it is possible to
know at which point in the worker's lifetime an event is done. Posting of
messages before a worker is started is allowed but posting them after the
worker has stopped is not.
This fixes avrorouter related failures and all other failures that stem
from worker messages being ignored at startup.
By stopping the REST API before the workers and moving the shutdown to the
same worker that handles REST API requests, we prevent the hang on
shutdown. This also makes the signal handler signal-safe.
If a worker has been stopped, tasks must not be executed on it. To prevent
this, the calling code should check whether the worker has been
stopped. This does not prevent the case where a message is successfully
posted to a worker but the worker is stopped before it processes it.
The slave connection I/O-tread stays running if replication credentials are
wrong when connecting to master. This causes a switchover/failover timeout.
When this happens, print the error in the slave connection status as this
clarifies the problem to the user.
If one slave is executing a query while another one is executing a session
command and the one that is executing the session command fails, the
ongoing query would get retried even though the server that failed was not
executing it. If the server was executing a session command, nothing needs
to be done.
RWBackend did not expect that a resultset and an unexpected ERR packet
could be stored in the same buffer. This can happen for example if a
server shuts down immediately after the resultset is sent.
If a packet with a KILL query was followed with another packet in the same
network buffer, the code wouldn't work as it expected to receive only one
packet at a time.
In MaxScale, a "deprecated" parameter is not in use and can be ignored.
Leaving the parameters out of serialized configuration files avoids warning
messages.
By iterating over the servers and sending the master's charset we are
guaranteed a "known good" charset. This also solves the problem where a
deactivated server reference would be used as the charset and server
version source.
If the execution of a session command fails on a master, it is retried
again. If the master is not available, the response will be returned from
one of the slaves.
The retrying of a read on a slave should only be done when the failing
server is waiting for a result and it was the last server from which a
result was expected.
If the master fails when a session command is being executed with
delayed_retry enabled, a null query would get placed into the query
queue. This change simply prevents the crash and closes the session even
though the query could be retried.
A query should not be queued if no responses are expected. The code that
executes queued queries should be dead code and this assertion would catch
it.
Older clients assume the plugin used for authentication is
mysql_native_password. If the client doesn't request plugin
authentication, don't treat it as an error.
The monitor queries for logged in users with super-privileges and kicks them out to
prevent writes to master. Normal users can stay since their writes are prevented by
read_only. Also, the master-status is removed from the master manually to signal to
routers that no more writes should go to master.
Plugins may send additional messages during authentication. These messages
often contain notifications such as password expiration dates. Both the client
and backend side authenticators now handle such messages. The messages are not
sent to the user, only the log. The requirement that only "Password: " is queried
still stands.
If a client requests an unknown binary protocol prepared statement handle,
a custom error shows the actual ID used instead of the "empty" ID of 0
that the backend sends.
The code that checked that only non-empty queries are stored in the query
queue was left out when the query queue fix was backported to 2.3. Since
MXS-2464 is caused by a still unknown bug, the runtime check should help
figure out in which cases the problem occurs.
