When checking the node info, also include information about wheter
a node is being SOFTFAILed. If it is, turn on the `Being Drained`
bit.
A node is SOFTFAILed with the intention of removing it, so better
not to create new connections to it as they later would be broken
when the node is actually taken down.
It is now possible to [un]softfail a Clustrix node via MaxScale
using a Clustrix monitor module command.
In case a node is successfully softfailed, the `Being Drained` bit
will automatically turned on. Similarly, if a node is successfully
unsoftfailed, the `Being Drained` bit will be cleared.
Since the settings are now protected fields, all related functions were
moved inside the monitor class. mon_ping_or_connect_to_db() is now a method
of MXS_MONITORED_SERVER. The connection settings class is defined inside the
server since that is the class actually using the settings.
The test appears to have failed at least once when the monitor did not,
for some reason, notice that a server was down. Also adjusted the queries
to be more unique across the test cases.
This commit adds a new parameter that, when enabled, prunes the session
command history to a known length. This makes it possible to keep a
client-side pooled connection open indefinitely at the cost of making
reconnections theoretically unsafe. In practice the maximum history length
can be set to a value that encompasses a single session using the pooled
connection with no risk to session state integrity. The default history
length of 50 commands is quite likely to be adequate for the majority of
use-cases.
When the connection state is reset by executing a COM_CHANGE_USER or
COM_RESET_CONNECTION, readwritesplit does not need to store the session
command history that was executed before it. With this, pooled connections
will effectively behave like normal connections if the pooling mechanism
is smart enough to reset the connection. This also prevents unwanted
visibility into the session states of other connections.
If the routing of a session command fails due to problems with the backend
connections, a more verbose error message is logged. The added status
information in the Backend class makes tracking the original cause of the
problem a lot easier due to knowing where, when and why the connection was
closed.
Sometimes that's what you want, but primarily for completeness'
sake and it makes AUTO more sensical as it essentially chooses
beteen DIRECT and QUEUED mode.
TODO: This much explanation in the release notes is a bit too
much, the beef should be moved somewhere else and the release
notes simply refer to that.
When looking for a master, if it does exist it should be found
even if it is not connectible. The fact that it is not connectible
should be dealt with when a connection is created.
If a master is found but it is being drained, the connection attempt
is rejected if the master failure mode is fail_instantly.
In that case the logged message makes it plain that it is the draining
that is the reason for the connection attempt to fail.
