Updated links and module names in the configuration. Also changed object
names so that they don't produce warnings. Removed redundant parameters
and tuned default monitor_interval to a slightly more reasonable 2000
milliseconds. Enabled automatic thread number configuration.
- 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.
- Take down the current master and wait a while (failover assumed
to happen).
- Put up the old master node and wait a while.
Keep on doing that for 1.5 minutes.
At the end check that:
- There is one 'Master'.
- The other nodes are either
- 'Slave' or
- 'Running' in which case it is checked it is because the node could
not be rejoined.
The output generated by a failed call to a module command was previously
overwritten with the error messages stored in the module command
subsystem.
In the case of a failure, the proper procedure is to check if the output
generated by the module command conforms to the JSON API error
specification and if it does, combine it with any system generated error
messages. If the output does not conform, it is stored in the "meta" field
of the returned object. This allows all of the generated output to be
saved.
Using commas instead of spaces prevents a the misinterpretation of
commands as hostnames. If the `--hosts` option was given just before a
command, it would consume the commands as arguments to the `--hosts` list.
Only asynchronous authenticators require the thread-specific loading of
users as the synchronous ones all share the same data. If the service does
not declare asynchronous capabilities at startup, the users are not
seeded. This prevents unnecessary loading of users at startup.
If node00 is not the master when a test is started, the cleanup
performed by TestConnections takes considerable time.
By restoring the sitation back to normal before ending the test,
the startup time of the next test can be shortened significantly.
Time elapsed is now properly tracked during a switchover. After slave
redirection, an event is added to the master. Then, the slaves are queried
repeatedly until they advance to the newest event. I/O and SQL errors are
also detected.
Now that mariadbmon supports failover and switchover, a test may
may change the master to some other node than node 0.
Consequently, as part of fixing the replication, gtid_slave_pos
of node 0 must be reset as well.
As the stale status is not a real status bit and it's used to retain the
history of a master, there is no need to print it in any output. This
output will only confuse users now that the stale status will not be
cleared from masters that go down.
The test uses standard setup (1xMaster, 3xSlaves).
1. Shutdown master (server 1), check that autofailover promotes
a new master.
2. Stop MaxScale.
3. Start server 1 and add some events to it so it can no longer rejoin
cluster.
4. Start MaxScale, check that server 1 does not join.
5. Set current master to replicate from server 1, turning it to a relay
master.
6. Check that server 1 is master, all others are slaves (due to auto-rejoin).
The log manager could send two messages if a log message was posted soon
before the log manager was stopped. This caused a debug assertion which
then manifested as a deadlock inside the log manager.
