When running BLR locally, you need to be able to specify what
IP the BLR is visible at (127.0.0.1 does not work for VM nodes)
and also to perform cleanup etc. action when needed.
The test adds a scheduled server event, the does failover, rejoin and
switchover and checks that event is manipulated correctly. Also includes
a change to the monitor to fix an invalid ALTER EVENT query when the event
definer has wildcard host.
If a test program needs other than the default Galera config
(e.g. log_slave_updates enabled), then it should be able to
programmatically cause galera to be restarted as part of the
TestConnections construction.
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.
If the test would otherwise succeed but a coredump is found when the logs
are copied in the destructor, the test would pass. To prevent this, the
destructor should always exit with a non-zero status when it detects an
error.
Streamlined the test to perform as much testing as fast as possible. The
gradual ramp up did not provide any concrete benefits compared to testing
everything at once.
Replaced structures with C++11 alternatives where possible and removed
unused, redundant or dead code.
Before the state of the backend servers is checked, MaxScale needs to be
stopped to prevent the automated failover from interfering in the start-up
process.
The test should stop MaxScale at the start unless the manual debug flag is
given on the command line. This fixes the connection failure of mxs1719
but reveals a problem with the filter itself.
The tests failed to compile due to invalid use of try_query. For some
reason this wasn't detected by newer compilers.
Also fixed the compilation failure of mxs1713_lots_of_database on CentOS
7.
The test unnecessarily did an unconditional drop of the user resulting in
errors. Also prevented stopping of MaxScale if it wasn't started in the
first place.
Now, if a test is invoked with '-l', then MaxScale is assumed to
be running locally using a configuration file suitable for the
test that is invoked. Further, at the end of the test, the log
files of MaxScale are not downloaded (obviously).
As a side-effect, an environment variable no_maxscale_log_copy,
similar to the existing no_backend_log_copy, has been introduced
using which the downloading of maxscale log files unconditionally
can be prevented.
The test may fail if the client/maxscale/mariadb combo is too slow.
TODO, maybe: today I saw mysql_query() hang (in a poll) when maxscale
disconnected. Is there something that can be done about that?
I added a source directory, base, for stuff that should become part of a common
utility library in the future.
By truncating the files, tests can be run while the log is being
tailed. If they are removed, the files need to be reopened each time a
test is started.
The test now flushes the INPUT chain of iptables at the start of the
test. This should open all ports even if the OS by default defines some
rules that block ports.
The test can now be run outside of the test source directory. Since the
`test_dir` global variable contains the absolute path to the test source,
all copying of configurations and execution of scripts can be done with
minimal changes.
The previous core check would pick up any file in /tmp/ that would start
with the `core` prefix. This included some npm generated files which are
created if MaxCtrl is built on the MaxScale machine.
The test checks that failover works even when the master of the monitored
cluster is a slave to an external masters. The test also verifies that the
servers do not get unexpected status labels.
