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.
The test uses a separate writer thread to insert data into the
master. This thread must be halted before the blocking of the master
happens as the slaves must catch up. Once slaves have caught up and the
master is blocked, the writer thread can continue doing inserts.
At the end of the test slaves must also be synchronized before the
inserted data is validated. This prevents test failures due to slave lag.
Tests that local_address is taken into account. However, at the time
of writing the maxscale VM does not have two usable IP addresses, so
we only test that explicitly specifying an IP-address does not break
things.
Locally it has been confirmed that this indeed works the way it is
supposed to.
The test repeatedly blocks and unblocks a master which goes unnoticed by
the monitor due to the 10 second read timeouts in the monitor
configuration in the longblob template. The replication template uses the
default timeouts which makes the test actually exercise the functionality
that it is intended to test.
The test now also creates TIME type values and checks that they are
converted correctly. Also added NULL value tests for all values and made
required adjustments to the code.
The CDC connector can be build directly into the core testing library for
testing purposes. This way we remove an unnecessary dependency on a
library. This commit fixes the linkage failure of the cdc_datatypes test.
Now that the connector resides in the same repository, it can be built as
a library for the tests. Installing the development package is one option
but it would unnecessarily complicate the build process.
The pre-existing users in the MaxScale test environment have
the super privilege so they are not affected by the database
being set in read-only mode.
Consequently, a custom user without the super privilege must
be used by the client threads.
- Start 4 threads where each thread sits in a loop and performs
20% updates and 80% selects. Each thread has a table of its own.
- The main thread executes the following in a loop.
- Perform a switchover from the current master to the next (which is
simply the next node % all nodes).
- Keep on doing that for 1.5 minutes.
The expectation is that the switchover will succeed, that is, after the
operation there will be a new master.
