The table creation was not detected as the function used to extract the
table name did not return the fully qualified names. Even if it did return
a fully qualified name, it wouldn't have been correctly processed.
The test did not use the wait_for_monitor function to sync with the
monitor. This function speeds up the testing greatly by removing
unnecessary sleeps from it.
Also reduced the amount of data inserted into the cluster. There's no real
need to test with large amounts of data as it is only a functional test.
If the test fails, there's no point in continuing with the load generation
as it only serves to slow things down. In few cases the test caused
std::bad_alloc to be thrown which prematurely stopped the ctest run.
Now the test program will
1) Write to each node in a Galera cluster and verify that the data
ends up in the slave.
2) At the end of 1) execute STOP SLAVE and START SLAVE to check that
replication can be stopped and started again (won't work unless
each node has the same server_id and value for @@log_bin_basename).
3) Block the node BLR is replicating from and expect it to connect
to the next configured master and that replication continues to
work. Do that for all nodes.
4) Stop MaxScale and restart it and expect 3) to work. That checks
that BLR saves all necessary information in master.ini and is
capable of reading it.
It should be possible to START SLAVE and STOP SLAVE irrespective
of which Galera node updates are mode to.
That will be the case if @@log_slave_updates is on and each node
in the Galera cluster have the same server id. Otherwise it will
fail with the current incarnation of BLR.
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 now checks that default database usage works as expected. This
currently only works with RBR and with SBR it fails due to inadequate
processing of the SQL statements (default database is not concatenated
into the table).
If
* BLR replicates from a node in a Galera cluster and
* writes are made to all nodes in that cluster,
then
* if a slave to BLR is stopped when it has received an event
originating in a node different than the one BLR is replicating
from
the subsequent (re)starting of the slave will fail because BLR looks
for the last event from a file whose path contains the server id of
the node where the event originates, although it should look for it
in the file whose path contains the server id of the node from which
BLR replicates.
The test adds events to the backends, causing them to go out of sync. It then
uses the reset-replication command to fix the situation and checks replication
is working.
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.
