If the client sends data before authentication is complete, it must not be
discarded and it needs to be processed like as if it was sent in a
separate network packet.
Switchover expects one or two servers as argument, one (the new
master) if there is no master and two (the new master, and the
current master) if there currently is a master.
The procedure is as follows:
- Stop monitor
- Check that provided arguments are reasonable.
- If there is no master currently, then only one argument is
accepted.
- If there is a master, then it must also be specified.
This is to prevent pathological cases where the situation has
changed after the admin has issued the switchover command.
- Check the failover mode and disable it.
- Perform the failover.
- If succeeded, enable failover if it was.
- If it failed, if failover was enabled, do not enable it and log
an alert. If failover was not enabled, just log an error.
If a module command returns a json object, it will always be
returned to the caller, irrespective of whether the command
itself succeeded or not.
Otherwise, if the command failed and if the module command has
set an error message, that error message will be returned as a
json object containing the error message.
If a module command returns a json object, it will always be
returned to the caller, irrespective of whether the command
itself succeeded or not.
Otherwise, if the command failed and if the module command has
set an error message, that error message will be returned as a
json object containing the error message.
Since the module command interface was expanded to include a JSON output
parameter, there is no longer a need for an output DCB. As the JSON can be
printed by both maxadmin and the REST API, this allows the removal of
explicit output formatting in module commands.
Tentative documentation.
With the 'switchover' config variable the switchover functionality
can be enabled. If enabled a REST API endpoint will appear, using
which that switchover can be initiated.
Switchover can only be performed when MaxScale is in active mode
and failover will be disabled for the duration of the switchover.
Only if the switchover succeeds, will failover be enabled again.
Might be easier to expose that REST API always and only change
the behaviour when calling it, instead of making it appear and
re-appear.
The `failover` and `failover_timeout` parameters are now declared as a
part of the mysqlmon module. Changed the implementation of the failover
function so that the dependencies on the monitor struct can be removed or
moved into parameters.
Split the state change processing and failover handling into two separate
functions and added a call to the failover function into mysqlmon. This
prevents unintended behavior when failover is enabled for non-mysqlmon
monitors. The parameter itself still needs to be moved into mysqlmon.
Moved the failover documentation to the mysqlmon documentation as it is
specific to this monitor.
The failover command is simulated by executing a call to /usr/bin/echo
with all possible monitor parameters. This allows testing of the failover
mechanism without actually using the failover command.
The `script_timeout` and `journal_max_age` parameters weren't handled in
the monitor alteration code.
Also added missing documentation to maxadmin help output for
`alter monitor`.
When the database firewall filter is used in white-list mode,
'USE <db>' should be allowed. When connecting, it is always
possible to specify the database anyway so restricting
'USE <db>' serves no purpose.
The result of the authentication should be ignored but the scramble that
is calculated as a side-effect still needs to be stored. This can be done
by altering the SQL used to get the matching row to only match on the
username, not the network address.
Also expanded the test case to cover the use of bad credentials.
The avrorouter now uses the parameters from the source service. This
removes the need for redundant parameter definition in the avrorouter
service when they are defined in the binlogrouter service as parameters.
Added some missing configuration sanity checks and updated the tutorial to
reflect the new configuration method introduced in 2.1.
The documentation stated that the binlogrouter would use the cache
directory to store the binary log files. In reality, there was no default
value and the service would fail to start without a binlogdir parameter.
The router now uses the data directory (/var/lib/maxscale/) to store the
binary logs.
Set the default value of mariadb10-compatibility to true. This is in line
with the fact that most installations should use the router with a MariaDB
10.0 server or newer.
If a prepared statement fails to execute on a backend server, no prepared
statement ID is returned. As the connection to the slave backend will be
closed when the result of a session command differs from the master's
response, there's no need to even attempt extracting the response.
This change avoids the triggering of a false positive in
mxs_mysql_extract_ps_response when an attempt to extract a
COM_STMT_PREPARE response is made on a response that isn't a
COM_STMT_PREPARE response.
When readwritesplit is routing any queued queries, the currently executed
command of the protocol modules needs to be adjusted by
readwritesplit. This is not a true fix but more of a workaround to fix the
problems of queued query execution.
The correct solution would be to move the queued query handling into the
client protocol module so that all components see the same state.
Asserting that only a complete COM_STMT_PREPARE is returned when the
prepared statement preparation is extracted will guarantee that the
protocol works as expected.
If a prepared statement sends large amounts of data, the target server
where the data is sent will be tracked. The tracked target was not reset
after a multi-packet query was completed and the target itself was used to
check whether the session was processing a multi-packet query.
Changed the check to use the boolean variable instead of the target and
added a reset of the tracked target after a multi-packet query was
completed.
The new parameter allows the session to be "locked" to the master server
after a stored procedure is called. This will keep the session state
consistent if the stored procedure call modifies the state of the session.
The monitor performs simple monitoring of a group replication cluster. It
expects no extra parameters in addition to the common monitor parameters
and will only set master and slave status bits on the servers. It is a
part of the experimental package as it is a very experimental module.
Further improvements would be to add the usage of the synced state.
