When the SERVER_BEING_DRAINED bit is on, if the number of connections
to the server is 0, the state is reported as "Drained", otherwise as
"Being Drained".
Moved hintfilter documentation to the correct place and cleaned it
up. Added a note at the start of the syntax documentation about the
behavior of the hint parsing to warn users of possible unexpected
behavior. The hint parsing could really use some refactoring to make it
more manageable which is why the preliminary fix version of the bug will
be 2.4.
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.
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.
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.
Names starting with '@@' can now longer be used in configuration files.
Subsequent commits will prevent such names from being used when objects
are created dynamically.
Both the replication lag and the message printing state are saved in SERVER,
although the values are mostly used by readwritesplit. A log message is printed
both when a server goes over the limit and when it comes back below.
Because of concurrency issues, a message may be printed multiple times before
different threads detect the new message state.
Documentation updated to explain the change.
