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.
The schema router now deals with the being drained bit the same way
it deals with the maintenance bit, that is, a server being drained will
simply be ignored.
TODO: This behaviour needs to be document.
TODO: It seems the schema router simply ignores the maintenance bit
once a connection has been establisdhed.
Currently the bit is set so that is may be overwritten by the monitor
if the setting of the bit takes place while the monitor is performing
its monitor loop.
With this bit set, existing connections to a server should not be
closed, but no new connections should be created to the server.
The bits have also slight been rearranged.
- Bits 0 - 15 are now reserved for bits applicable to all servers
- Bits 16 - 31 are monitor specific
Further, the cases whether a server can be connected to and whether
it can be used, but be separated.
If a server was not chosen as the target of a routing hint, the server
status would not be logged. By logging the server state in the message, it
is easier to figure out why a server wasn't chosen as the routing target.
Once the monitor has been able to connect to a clustrix node
and obtain the clustrix nodes, it'll primarily use those nodes
when looking for a Clustrix node to be used as the "hub".
With this change it is sufficient (but perhaps unwise) to provide
a single node boostrap node in the configuration file.
Some other rearrangements and renamings of functions has also been
made.
