The result collection did not reset properly when a non-resultset was
returned for a request. As collected result need to be distinguishable
from single packet responses, a new buffer type was added.
The new buffer type is used by readwritesplit which uses result collection
for preparation of prepared statements.
Moved the current command tracking to the RWBackend class as the command
tracked by the protocol is can change before a response to the executed
command is received.
Removed a false debug assertion in the mxs_mysql_extract_ps_response
function that was triggered when a very large prepared statement response
was processed in multiple parts.
Inlined the getter/setter type functions that are often used. Profiling
shows that inlining the RWBackend get/set functions for the reply state
manipulation reduces the relative cost of the function to acceptable
levels. Inlining the Backend state function did not have as large an
effect but it appears contribute a slight performance boost.
The result processing code did unnecessary work to confirm that the result
buffers are contiguous. The code also assumed that multiple packets can be
routed at the same time when in fact only one contiguous result packet is
returned at a time.
By assuming that the buffers are contiguous and contain only one packet,
most of the copying and buffer manipulation can be avoided.
The parameter handling for monitors can now be done in a consistent manner
by establishing a rule that the monitor owns the parameter object as long
as it is running. This will allow parameters to be added and removed
safely both from outside and inside monitors.
Currently this functionality is only used by mysqlmon to disable failover
after an attempt to perform a failover has failed.
KILL commands are now sent to the backends in an asynchronous manner. As
the LocalClient class is used to connect to the servers, this will cause
an extra connection to be created on top of the original connections
created by the session.
If the user does not have the permissions to execute the KILL, the error
message is currently lost. This could be solved by adding a "result
handler" into the LocalClient class which is called with the result.
When the LocalClient is constructed, it is possible to extract all the
needed information at that time. The only obstacle is the fact that the
LocalClient is constructed at the same time the session is. Since the
client DCB is created before the session, it is safe to extract the shared
data directly from it.
If a switchover_script parameter is given, its value will be used as
the switchover script. Otherwise the default will be used. Currently
just echo.
The MySQL Monitor now introduces two script variables, CURRENT_MASTER
and NEW_MASTER, that contain information about the current and new
master respectively.
Switchover is performed only if switchover has been enabled and MaxScale
is *not* in passive mode.
The total timeout for the retrying of interrupted queries can now be
configured with the `query_retry_timeout` parameter. It controls the total
timeout in seconds that the query can take.
The actual connection, read and write timeouts of the connector aren't a
good configuration value to use for abstracted queries as the time that it
takes to execute a query can be composed of both connections, reads and
writes. This is caused by the usage of MYSQL_OPT_RECONNECT that hides the
fact that the connector reconnects to the server when a query is
attempted.
The new `query_retries` parameter controls how many times an interrupted
query is retried. This retrying of interrupted queries will reduce the
rate of false positives that MaxScale monitors detect.
To be able to do that, we need to get hold of the MXS_MONITORED_SERVER
corresponding to the SERVER specified as the new master.
So, instead of just return a boolean indicating whether the server was
found or not we return the MXS_MONITORED_SERVER pointer.
