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.
Make all modules lowercase and make module loading case
insensitive. Further, make command invocation case insensitive,
as far as the module name is conserned.
During switchover, MASTER_GTID_WAIT is now called on all slaves. This causes
switchover to complete slower than before but is safer if log_slave_updates
is not on on the new master server. Also, read_only is disabled on the
demoted server if waiting on slaves or promotion fails. This should
effectively cancel the failover for the old master.
The `purge` command can be used to reset the conversion
process. Currently, executing the `purge` module command and restarting
MaxScale is the only correct way to reset the conversion process.
Added more debug assertions to JSON serialization of the Avro schema. Also
checked that the column count for the TABLE_CREATE object matches that of
the TABLE_MAP object.
The test loads multiple modules in one call so we have to pre-load them
one by one to make sure that they are all present regardless of the
locations where the individual modules were built.
All modules now have an 8-bit range for capability flags. Currently only
the client side authenticator and protocol capability bits are loaded due
to the fact that backend versions of these modules don't relate to a
particular service.
