The test performs the following:
CREATE tbl (x INT PRIMARY KEY)
t1 t2
BEGIN BEGIN
INSERT INTO tbl VALUES (1)
SELECT * FROM tbl FOR UPDATE
That will cause t2 to wait.
INSERT INTO tbl VALUES (0)
That will cause t2 to be rolled back due to a deadlock.
Without transaction replay, the SELECT will return with an error.
With transaction replay, the deadlock error will be caught, the
transaction replayed and SELECT will return successfully.
Before the MXS-2250 fix, the following ends with an error:
CREATE TEMPORARY TABLE t (f INT);
DESCRIBE t;
Reason is that the first is sent to the master (and the table will
not be replicated to slaves) and the latter to some slave.
The bug appears when a session command that is executed on the master
fails. The logic in the code doesn't take this case into consideration
when it processes failed connections.
Take down a node other than the one we are connected to, which
will cause a group change error, and test that MaxScale catches
that and replay the transaction.
The purpose of this class is to make it easy from a test program
to access the output of the REST-API. Currently it provides only
the equivalent of "maxctrl list servers", but it can be extended
if and when additional needs arise.
Right now it's implemented so that curl is executed on the 0th
MaxScale instance, using the ssh mechanism of the test framework.
The test appears to fail to connect to MaxScale due to unavailability of
connections. Theoretically, the improvement in accept speed due to
SO_REUSEPORT additions could explain the faster exhaustion of available
sockets.
Implementations of check_replication() and start_replication() for Clustrix allows to use fix_replication()
also for Clustrix nodes without checking it.
Also several attempts to check nodes after restart are added - to wait for nodes if they are not running
right after server daemon restart
