SSLContext is now used everywhere except the binlogrouter which still
allocates the contexts itself. Fixing the binlogrouter's misuse of
internal structures is a rather large undertaking and for this reason the
SSLContext will be taken into use there in a separate commit.
Currently it's too laborious to use duration suffixes when saving
generated configs and also to handle suffixes when changes are made
dynamically using maxctrl.
It will be trivial to do that when the new configuration mechanism
has been taken into use everywhere. That will not happen before
MaxScale 2.5.
So, in MaxScale 2.4 duration suffixes will be accepted in manually
created configuration files, but no warning will be logged if a
suffix is not used.
See script directory for method. The script to run in the top level
MaxScale directory is called maxscale-uncrustify.sh, which uses
another script, list-src, from the same directory (so you need to set
your PATH). The uncrustify version was 0.66.
The variable storing the configuration index renamed from
'current_config' to 'config_index'.
In the code the same terminology is used as in the documentation.
"Default" is is used for referring to the default connections
(earlier "primary" was used) and the secondary connections are
referred to as "secondary" (earlier "alternative" was also used).
0 cannot be used to indicate failure as 0 will be the waiting
period if we switch to an alternative server.
Also fix some minor issues; failure to initialize all members
and inverted success-check.
Separating the reading of the config from the process of
applying it allows us to use configs around and later apply
them (e.g. when we decide its time to switch master server).
At save time, assert that the configuration as dispersed around
blr and as stored in the config object are identical.
Later its the state from the config object that will be saved.
Alternative masters can now be specified like
CHANGE MASTER TO ...
CHANGE MASTER ":2" TO ...
CHANGE MASTER ":3" TO ...
Now only the data is stored, but it is neither used nor
saved.
To prepare the router's for the eventual removal of the router_options
parameter, the API option arguments should not be used. The parameters can
be substituted by tokenizing the value of the parameter that is still
stored as a part of the service.
This clarifies what parts of the router are specific to the binlogrouter
and what are common between the binlogrouter and avrorouter.
Ideally, the two modules would use the same infrastructure to handle the
processing of replication events. This is the first, albeit small, step
towards making the code in the binlogrouter the common infrastructure.
