The slave nodes par od the cluster are sorted by wsrep_local_index or
server priority.
The sorted list od nodes is then used in ‘wsrep_sst_donor’ variable.
Note: candidate master servers are always at the end of the list
Galeramon queries all slave nodes for SHOW VARIABLES LIKE
'wsrep_node_name'
The server list, currently not sorted, is used in SET GLOBAL
wsrep_sst_donor = “list”. The statement is sent to all slave nodes
All modules now declare a name for the module. This is name is added as a
prefix to all messages logged by a module. The prefix should help
determine which part of the system logs a message.
The header is divided into two parts, an external and an internal one. The
actual splitting is done in a later commit and this commit only prepares
the header for the split.
This removes parts of the nearly identical code from all monitors.
The removal of monitor type specific event checking is done based on the
assumption that only the monitor that is monitoring the server can be the
cause for a state change. This removes the need to actually check that the
state change is relevant for each monitor and allows the event handling to
be moved into the core.
- All (but the printing/debug functions) are now in snake_case.
- Functions made const correct.
- All function prototypes now have named arguments.
Documentation still to be moved, and file possibly split into
include/mascale/server.h and server/core/maxscale/server.h
The MXS_MODULDE object now contains optinal pointers for functions
to be called att process and thread startup and shutdown. Since the
functions were added to the end, strictly speaking, all structures
would not have needed to have been modified, but better to be
explicit. In a subsequent change, these will be called.
C++ does not support flexible arrays, so for the time being C++
modules are restricted to 10 parameters. Better approach is to
factor out the parameters to a separate array and then just store
a pointer to that array in MXS_MODULE.
All monitors now declare the parameters that they use. This allows the
core to check the validity of the parameters before they are passed to the
monitor. It also simplifies the processing of the parameters as they are
guaranteed to be valid.
The MODULE_INFO is now the main object which is used by modules to convey
information to the MaxScale core. The MXS_MODULE name is more apt as it
now contains the actual module definition.
The old MODULES structure was moved into load_utils.c as an internal
implementation and was renamed so that it is not confused with the new
MODULE structure.
The modules are now declared with a common macro. This allows future
additions to the module loading process while also making the loaded
symbol name a constant.
This allows modules to only expose one entry point with a consistent
signature. In the future, this could be used to implement declarations of
module parameters.
The functionality to disable setting of master and slave status values to
Galera nodes was broken by the change to the monitoring algorithm.
The disable_master_role_setting option removed the master node which would
trigger the clearing of the replication status values from the node. A
more direct, and arguably better, way is to check that this option is
disabled before processing the status values for the nodes.
Previously, server status changes from MaxAdmin would be set immediately
as long as the server lock could be acquired. This meant that it might take
several seconds until the next monitor pass is executed. Usually, this was
fine but in some situations we would want the monitor to run immediately
after the change (MXS-740 and Galera). This patch changes the logic of
setting and clearing status bits to a delayed mode: changes are first applied
to a "status_pending"-variable, and only once the monitor runs will the
setting be applied. To reduce the delay, the monitor now has a flag
which is checked during sleep (between short 0.1s naps). If set, the
sleep is cut short.
If a server is not monitored, the status bits are set directly.
There is a small possibility of a race condition: If a monitor is stopped or
destroyed before the pending change is applied, the change is forgotten.
When a Galera cluster loses a member, it will recalculate the
wsrep_local_index values. As the index is zero-based, we can be certain
that in a valid cluster there will always be a node with an index of 0.
If the galeramon can't find a node with an index of 0, it means that
either the cluster hasn't stabilized and there's a pending recalculation
of the index or that there's no connectivity between MaxScale and the node
with the index value 0.
With this change and default settings, active-active MaxScale setups with
Galera clusters should always choose the same node as the master.
MXS-873 To prevent monitors and MaxAdmin from interfering with each other,
changes to the server status flags now happen under a lock. To avoid
interfering with monitor logic, the monitors now acquire locks to all
of their servers at the start of the monitor loop and release them
before sleeping.
The MySQL Monitor did not reset the pointer to the root master reference
which would lead to a crash if the master was removed.
When service details were shown, it listed all servers that existed. Only
servers that haven't been removed or destroyed should be shown.
The server credentials are only used if both the monuser and monpw
parameters are defined. This is a sort of a bugfix as a monitor connection
could use a username from server but a password from the monitor.
The address, port, monuser and monpw parameters of an existing server can
be changed at runtime. The support for enabling SSL will come in a later
commit.
Allowing servers to be modified could also be done by destroying and
recreating them. Since the servers are never actually destroyed, it is
better to allow the alteration of the existing ones.
MaxScale can now start without any defined monitors. This allows the core
services to be configured beforehand. With the changes to dynamic
modifications to servers, automatic scaling of slaves is possible.
The hangup code was refactored into a common function which should only be
used after the server states have been updated. This will remove erroneus
connections to already failed servers.
If a Galera node has a nonpositive priority, the node will never be chosen
as the master. This gives the user more control over how the master is
chosen.
When a master server is set into read-only mode, it can be treated as an
always up-to-date slave. This gives us a somewhat graceful way to prevent
writes to a master.
Usually setting the master into read-only mode is done before a change in
the replication topology to prevent stray writes arriving on the
master. MaxScale should respect the read-only mode and not send any writes
to a server that's in read-only mode.
The general purpose stuff in skygw_utils.h was moved to utils.h
and the corresponding implementation from skygw_utils.cc to utils.c.
Includes updated accordingly.
Skygw_utils.h is now only used by log_manager and by mlist, which
is only used by log_manager. Consequently, skygw_utils.h was moved
to server/maxscale.
Utils.h needs a separate overhaul.
- STRERROR_BUFLEN moved to cdefs.h and renamed to MXS_STRERROR_BUFLEN.
Better would be to provide a 'const char* mxs_strerror(int errno)'
that would have a thread specific buffer for the error message.
- MIN and MAX also moved to defs.h as MXS_MIN and MXS_MAX.
- Now only mlist.h of the headers depend upon skygw_utils.h.
- All now include maxscale/cdefs.h as the very first file.
- MXS_[BEGIN|END]_DECLS added to all C-headers.
Strictly speaking not necessary for private headers, but
does not hurt either.
- Include guards moved to the very top of the file.
- #pragma once added.
- Headers now to be included as <maxscale/xyz.h>
- First step, no cleanup of headers has been made. Only moving
from one place to another + necessary modifications.
As the failover status check is done after the pending status has been
moved to the current status, the do_failover should set the current status
of the server as Master.
The mysqlmon simple failover mode allows it to direct write traffic to a
secondary node. This enables a very simple failover mode with MaxScale
when it is used in a two node master-slave setup.
