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.
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.
