Was deprecated in 2.3. Similar features are in MariaDB-Monitor.
One system test was modified to use MariaDB-Monitor instead. Some parts
of the test are disabled for now to make it pass.
The lazy connection creation reduces the burden that short sessions place
on the backend servers. This also prevents the problems caused by early
disconnections that happen when only one server is used but multiple
connections are created. This does not solve the problem (MXS-619) but it
does mitigate it to acceptable levels.
This commit also adds a change to the weighting algorithm that prefers
existing connections over unopened ones. This helps avoid the
flip-flopping that happens when the absolute scores are very similar. The
hard-coded value might need to be tuned once testing is done.
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.
